28 réponses à ce sujet

[henesua]

[EDIT 2016 july 27]
This project is on the Vault
http://neverwinterva...s-onchat-script 
[/EDIT]

 I am rewritting some of Layonara's AID scripts to work with the player chat event and integrate with the DMFI emotes system. Its going well, and I should have this working in my module soon.

I have two questions:
(1) Is there any interest amongst other scripters to use this? Should I post an upgraded AID to the vault?
(2) What is the general feelign towards such thngs as a player or DM? I know there will be those that feel strongly about it one way or the other, but am looking for whether there is much interest or disdain for such systems beyond a vocal minority.

Modifié par henesua, 27 juillet 2016 - 10:17 .

[kalbaern]

Can you give a bit more detailed explanation of what the system does? I looked over the linked page and even there its kind of vague. I.E., how it works/is used would help us better determine if anyone else might use it.

[Fester Pot]

Kalbaern, think of it as an extended description script. So instead of coming across a placeable that you can simply view its description, you can also use AID through the chat event to learn a little bit more by "looking" for other clues or descriptions in that area.

Where a builder may put a picture that is useable and has a description above a fireplace, with the AID system, that builder can put a picture placeable and let the function of the AID system handle the rest.

*looks at picture above fireplace*

AID looks for chat hook matches LOOK, FIREPLACE, PICTURE, and spits out information.

*The picture may have been tampered with at some point, as one edge looks to have been disturbed*

FP!

[kalbaern]

Fester Pot wrote...

Kalbaern, think of it as an extended description script. So instead of coming across a placeable that you can simply view its description, you can also use AID through the chat event to learn a little bit more by "looking" for other clues or descriptions in that area.

Where a builder may put a picture that is useable and has a description above a fireplace, with the AID system, that builder can put a picture placeable and let the function of the AID system handle the rest.

*looks at picture above fireplace*

AID looks for chat hook matches LOOK, FIREPLACE, PICTURE, and spits out information.

*The picture may have been tampered with at some point, as one edge looks to have been disturbed*

FP!

OK, now that sounds useful indeed.

So my follow up questions are:

- Does hooking into the chat commands have significant overhead costs that could cause issues on a large PW?

- Does the AID System first make Spot or Search checks before revealing the extra information and if so, does the extra information gleaned vary dependent on the skill check results?

[henesua]

I will do my best to answer your questions, but if you download AID you can read their manual which goes into significant detail.

• Resources: I don't have data showing how resource intensive the chat event is but I don't believe it is significant. More importantly converting AID to use the chat event should imrove tis performance over the prior method which was to use "listeners" (which is the other option for doing this) because the event eliminates the requirement that a creature follow each player around and listen to what they say. For a point of reference... DMFI prior to 1.69 used listeners to process all of the chat commands. DMFI now uses the chat event and performance "feels" much snappier.
• Skill checks: There appears to be the option for skill check requirements for AID's events, but I have not looked closely at how this functions yet.

AID has 2 methods for responding to player chat commands. The first is a "Do" method which responds with AID scripted behavior depending on "verb" used. The second is an "On" method which allows the builder to specify a custom script for a "verb" used on a particular "object".  The On method performs a skill check prior to running the custom script. For any of the methods to work however, local variables need to be set on objects. So if you want the "examine" functionality to work on a particular object you need to set a local variable called "examine" on the object.

As a builder thats the fiddly part of this that is annoying. You have to explicitly flag game objects with the "verbs" that they will respond to.

As a player you have to get used to typing commands in the chat bar rather than just using the "tab" key to highlight active objects. To see what nearby objects are available you type in "look around", and a list of AID objects will show up. This works for my module because I use lots of text feedback for players already such as area descriptions, object descriptions, triggers that provide descriptions, feats like the track feat also provide descriptive text feedback, etc....  But if the module does not provide much descriptive text I can see this system as jarring for a player.

[wyldhunt1]

Looks like it has a lot of potential.
At the very least, I'd be willing to test it as long as it didn't use a listener any more.

[kalbaern]

henesua wrote...

I will do my best to answer your questions, but if you download AID you can read their manual which goes into significant detail.

• Resources: I don't have data showing how resource intensive the chat event is but I don't believe it is significant. More importantly converting AID to use the chat event should imrove tis performance over the prior method which was to use "listeners" (which is the other option for doing this) because the event eliminates the requirement that a creature follow each player around and listen to what they say. For a point of reference... DMFI prior to 1.69 used listeners to process all of the chat commands. DMFI now uses the chat event and performance "feels" much snappier.
• Skill checks: There appears to be the option for skill check requirements for AID's events, but I have not looked closely at how this functions yet.

AID has 2 methods for responding to player chat commands. The first is a "Do" method which responds with AID scripted behavior depending on "verb" used. The second is an "On" method which allows the builder to specify a custom script for a "verb" used on a particular "object".  The On method performs a skill check prior to running the custom script. For any of the methods to work however, local variables need to be set on objects. So if you want the "examine" functionality to work on a particular object you need to set a local variable called "examine" on the object.

As a builder thats the fiddly part of this that is annoying. You have to explicitly flag game objects with the "verbs" that they will respond to.

As a player you have to get used to typing commands in the chat bar rather than just using the "tab" key to highlight active objects. To see what nearby objects are available you type in "look around", and a list of AID objects will show up. This works for my module because I use lots of text feedback for players already such as area descriptions, object descriptions, triggers that provide descriptions, feats like the track feat also provide descriptive text feedback, etc....  But if the module does not provide much descriptive text I can see this system as jarring for a player.

[*]Definately sounds like something I'd use then.

[henesua]

Alright, I'll clean it up and finish my rewrites of the system. When finished I'll post it on the Vault.

That said however-- what are people's thoughts on how potentially jarring the system is?

[kalbaern]

henesua wrote...

Alright, I'll clean it up and finish my rewrites of the system. When finished I'll post it on the Vault.

That said however-- what are people's thoughts on how potentially jarring the system is?

I honestly cannot see how it would be jarring at all. Infact, I think it'd just heighten the "experience" when playing.

- If its chat based, most players that merely run around killing stuff rarely emote or RP and they'd be unlikely to even fire the system and notice.

- In the same vein, players that do RP and emote constantly likely will fire the system and find that it adds that little "extra something" thats often lacking and just adds to the immersion.

Will it be a "pain in the rump" and a lot of tedious work for builders to add? Possibly, but most likely when adding it to an older module. I know that I personally find such things worth the extra effort though.

[wyldhunt1]

I think it would be less jarring and more... ignored.
Players will forget that it exists and miss things.
I think players would have a lot of fun with it if it was used well, but it would need to be used often enough for the player to want to check the area often. If it always says there's no items near, they'll stop trying and miss the stuff that does use it.
I'd send a reminder that it's used when they log in, and maybe add a journal entry with instructions.
Then, use it in enough places to make sure that it's useful.

[henesua]

The reason why I have some concern about it is that typically players look for "secrets" in a module by doing two things (1) is to hold down the tab key and carefully look at everything on the screen and (2) slowly walk every square inch of an area with the "search" mode toggled on.

Those are the typical ways of "exploring".

This system however is completely invisible to those methods plus it requires that the player think of the game more in narrative terms which is an entirely different way of thinking about the game. That is what i think is jarring. It changes the way a player approaches the game.

For the module I am currently working on I don't think it is a problem because I immerse the player in narrative and description from the very beginning. The player is already required to do some reading and to consider game events within the context of what they have read. So adding a little more on top of this reading should not be a problem. HOWEVER for players that expect to ignore descriptions and fast forward to the action - if a puzzle is designed in game using the AID system I am sure they would be upset by that.

So that is my concern. What percentage of potential players will be turned off by a module that relies on AID?

[Fester Pot]

[quote]henesua wrote...
So that is my concern. What percentage of potential players will be turned off by a module that relies on AID?
[/quote]

Well it was used in a module but from the look of the comments, the AID system provided more headaches for players than it did enjoyment. Perhaps such a system would better be used in a full mystery type of module, where the AID was more of a tag-based script off of particular items that could share information - if you had said items - rather than a requirement?

From reading the comments, it seems there was no other way of completing certain quests without using AID. Two options could have been made available to the player - the normal way and the AID way - and if using the latter, perhaps extra experience could be awarded for finding more information about the quest than would otherwise be available.

An example -

You find a puddle of blood by the fireplace and your journal updates to tell you someone obviously was killed here as Bob mentioned when you met him. The quest advances as normal. If the player uses AID in the home, perhaps they learn of blood drips on the bedroom floor or in the hallway on the wall - added experience for investigating further. By no means does this change the line of the plot of someone being killed but by using AID, adds more touches to the murder and its investigation. The tool is there for the player to use - IF they choose to take the time to do it BUT it is not a requirement to complete the quest.

Some of the AID quotes from the player's who voted (only those quotes related to the system).

[quote]
Average storyline of going 3 different places to collect things, but like some others have commented, the AID system was a turnoff. Very time consuming.
[/quote]

[quote]
I thought AID was interesting, but kind of a pain to use even with hot keys.
[/quote]

[quote]
the aid system can be axed for descriptions of placeables
[/quote]

[quote]
AID: What's the point? Graphic environments of videogames were created for the purpose of *not* typing things like "pick up the mithral acid-coated gauntlet of DOOM". Good example is Xora's tower, where portraits could've just been made to be selectable and having descriptions...
[/quote]

[quote]
Weaknesses: at times the AID system seemed insufficiently integrated into the quests. In the murder investigation early on, which should really have been the high point of the AID system use, ended up being quite frustrating, because the PC's observations from AID were not always incorporated back into the conversations/questionings. For instance, when talking to the woman who my character has observed has a spellbook upstairs, my character can't bring this inconsistency up in conversation. I think this side quest had a lot going for it, and I am sucker for mysteries, but here the AID system just added frustration and inconsistency.
[/quote]

[quote]
AID was annoying at first but fine once I got the hang of it.
[/quote]

[quote]
The AID system should be in every module.
[/quote]

[quote]
Great Module, great story, AID system did not slow down the game for me.
[/quote]

[quote]
Awesome. I'd never seen the AID plugin before, and I love it. It makes for much better puzzles--players can't simply get around by clicking on things until they figure it out, you actually have to stop and read things.
[/quote]

[quote]
AID is good, once you get accustimed and are a good typist;
[/quote]

[quote]
AID didn't bother me at all and was sorta fun in a way.
[/quote]

[quote]
The AID system is a really good, very original idea but in the module it felt like a bit of a hassle to type all those orders instead of clicking.
[/quote]

[quote]
This had a lot of potential, but the reality is ridiculous. The AID system should never have been used. I played text-only games 25 years ago. What century is it again?
[/quote]

[quote]
I think the AID is very interesting, but I too became frustrated with the Mill Quest.
[/quote]

[quote]
Excellent mod, but I did mark it down for the AID system, which I found to be tedious and actually delayed information gathering.
[/quote]

FP!

Modifié par Fester Pot, 28 décembre 2011 - 12:26 .

[henesua]

FP -
         I'm still thinking over your comment, and considering how to best implement AID from a game play stand point. But my priority right now is to rewrite the AID system. I'll look at implementation after I have this rewrite done.

Everyone else -
         Getting close to a complete rewrite of a parser for emotes that integrates DMFI and AID.

Improvements so far:

• DMFI and AID get text from the player chat event rather than using a listener
• DMFI and AID can be processed together which limits overhead when using both systems.
• emotes are parsed regardless of where they are located in a chat string. Previously the start of the string had to contain an *. Now emotes are understood to be text contained by *'s.

             Example: Hello! *bows in greeting* It is good to see you. *looks around at the group*
             Result: And your character will bow. Previously you had to start the emote on a fresh line. I have not however created a way to queue multiple emotes in succession into the action queue so "looks around" will not result in another emote animation. Only the first "actionable" emote reesults in animation. AID however will not respond to bows and will instead keep looking for the first actionable verb to respond to. see below.

• AID's parser is smarter and more efficient. It now is smart enough to recognize words, and then whether the word is a verb, an ignored word, or an object. It no longer needs to strip "ignored words" from the emote string. In addition it is easy to make it smarter by creating more word lists such as prepositions, conjunctives, etc... by following the example set with the "ignored word list".

               what it does is looks for the first verb. then it starts looking for an object, while skipping over ignored words. If it encounters the end of the emote snippet before finding a suitable object or verb it will start looking for the first verb in the next emote snippet.
               example: Hello! *bows in greeting* It is good to see you. *looks around at the group*
               emote snippet 1: bows in greeting
               emote snippet 2: looks around at the group
               no actionable verbs are found in the first snippet. "looks" however is then found, and then "around" is identified as an object. AID parsing stops and then the "looks around" function is executed.


I am considering rewritting the DMFI emote parser further, so that it responds similarly to the way AID does - looking at each word one by one until it finds a match that it can do something with. OR ... I might give AID precedence - if AID finds an actionable verb that verb is the only one that will stimulate an animation. If however AID finds nothing that it can work with, then any emote will do for stimulating an animation.

Modifié par henesua, 28 décembre 2011 - 05:56 .

[henesua]

I uploaded to the vault my improvements to DMFI v 109. These are not strictly required to use my pending release of a revised Ambiguous Interactive Dungeons, but they are required if you want to integrate AID with DMFI. A few other improvements are included as well. Examples: that weird hanging behavior when the first player enters a module with DMFI 109 has been eliminated, and DMFI chat functions have all been extracted to an include so that they can be used with any Player Chat Event script.

[edit: uploaded my initial improvements to AID as well. I will post links to both projects when they are live. I curtailed my complete rewrite of AID so that I can get back to working on my module. If you have ideas I'll be ahppy to hear them. I am still on the fence about whether to completely rewrite the parser to more closely reflect the abilities of the z-machine style parser from Infocom, but the amount of work required is too distracting as I would prefer to continue producing my module which is due for its next play test in two weeks)

Modifié par henesua, 29 décembre 2011 - 09:33 .

[henesua]

Vault entries for what we've been talking about: 
Ambiguous Interactive Dungeons upgraded to version 3
Dungeon Master Friendly Initiative v1.09 patch

Modifié par henesua, 27 juillet 2016 - 10:19 .

[hexmendacious]

wyldhunt1 wrote...

I think it would be less jarring and more... ignored.
Players will forget that it exists and miss things.
I think players would have a lot of fun with it if it was used well, but it would need to be used often enough for the player to want to check the area often. If it always says there's no items near, they'll stop trying and miss the stuff that does use it.
I'd send a reminder that it's used when they log in, and maybe add a journal entry with instructions.
Then, use it in enough places to make sure that it's useful.

This.  I'm a HUGE fan of this idea - it creates a whole new layer and level of play, one wrapped up in narrative, which serves to complement role-play, I think.  But if it's not implemented well it can be a disaster - it reminds me a bit of the PAW (Player Action Widget) in the CRAP (classic Role-Playing Adaptation Project): I had a friend whose world I was exploring/testing that used the 'active search"  mechanism of the PAW (basically you target the ground you want to search, an animation of searching would play, and it would roll a Seach check and reveal stuff in a small radius of where you clicked upon success), and he excitedly told me to search around to find the hidden stuff - but I looked everywhere and never found anything, so eventually gave up.  So caution must be used to be sure to implement it well, but this is a great contribution.

[ShadowM]

I have a similar system already in HR base, that switch over the searching to a scripted form and does not use the game engine. I make them have to use to find traps and secret doors with, so they should get use to using it all the time and it a custom feat everyone has. No need to type, just click items, placables, door, ground.

[henesua]

ShadowM, that sounds like an alternative search system. AID is much more than that.

The biggest advantage of AID is that it allows for more detailed actions than are available in NWN's point and click interface. The second advantage is that "usable objects" do not need to be checked as "usable" in the toolset. This means that a player can not simply hold down the tab key to determine which objects are "important".

I like AID for multiplayer modules because in those environments players are more accustomed to emoting their character's actions, and AID is driven by emote text.

[ShadowM]

I understand what your saying. I think that if you combined the systems, you get the character more accustomed to using the system. As it is I think you get about 1 out 3 that use the system. Sounds interesting, I test it out when I get some more time.

[henesua]

Ah... I see what you are saying. Basically if AID is integrated with commonly used actions then Players will be more accustomed to using it in the module. That makes sense.

[henesua]

 I have begun integrating AID into a playable adventure. No play testing yet, but I am definitely making a point of creating a numer of objects that respond to it in each area so I think if I can keep this up, I should get good results from players. AND as I go I've been making improvements.
Improvements so far include:

• One thing that bugged me about the first implementation of AID was that actions with skill checks required the builder to create custom scripts. I've since begun restructuring the code so that actions with skill checks no longer require them. 
  Custom scripts will no longer be required for use of skill checks in AID.  Maybe now they'll see some use. I can't imagine they got much use before. So far this is just the case for push, pull, and examine. I'll keep going as needed until I have restructured all of the action functions.
• I have also improved the Push action, and added Pull to complement it. The original system pushed the object in one of four "cardinal" directions based on the direction the character was facing regardless of which side of the object the character was standing, which was weird and ugly on a number of levels. Also it sometimes failed depending on the tileset or the mesh of the placeable even when you should have been able to push the object. I've since fixed the bugs and improved the vector math so that the object is always pushed in a straight line away from the player. And then I added a "pull" action which allows objects to be pulled in a straight line toward (and past) the character. The parser also now accepts "shove(s)" for "push".
• I also think I will need to reimplement the custom actions portion of AID OR add a few built in actions to the parser to achieve some of the things I need for my own module. These actions are foraging related and I am not quite sure how to do it, but they are in the works.

I will likely have all of  this finished and posted to the Vault within the next two months. The reason for the long lead time is that I have to finish this adventure in Arnheim I am working on. Not until after that happens and is played through at least once and then improved upon will I get around to exporting systems out of the module and repackaging them for others to use. Then again I sometimes do foolish things and export systems in the middle of a project to the vault, so who knows.


Footnote - The foraging system in more detail than you probably want to hear:

• Something that I am considering as well is a system for foraging with periodically spawned objects at random locations. In Arnheim, if a wizard's familiar dies, they can't summon it anymore. They need to get a new one. One way to do so is to cast "Bind Familiar" on an animal of the same type. And since mice are awesome familiars, but really easy to kill, I think wizards will be in the market for mice, and so I need mouse holes with mice inside them. Anyway, the concept is to have hidden "mouse lairs" in the forest, field, and town. And there will be different ways to find these using AID and/or the Track feat. A similar system could be worked out with rabbit dens when an adventure needs to rustle up some dinner. These are basically invisible objects that can only be found when foraging for them. Otherwise players and monsters don't notice them, and I don't need to have small creatures running around the map for characters to hunt. Instead they find the lair and make use of it as a resource - or spawn the critter if that makes sense in the adventure.

Modifié par henesua, 09 mars 2012 - 03:33 .

[henesua]

Bug: I recently found a bug which I introduced by porting all of AID to the OnChat event and eliminating the listeners. AID has a set of chat commands which enable a player to repeat their last chat, to store chats in partiular memory slots, and to repeat chat text stored in a memeory slot. I did not realize that the text spoken by a player does not trigger an OnChat event - so these commands have been useless with regards to emote parsing by AID and DMFI.

Solution: I will need to create a special function that pipes text into the emote parsing functions - AND call this special function when a player uses the <last command or one of the <mem slots to repeat a phrase.

Modifié par henesua, 13 mars 2012 - 10:19 .

[Rolo Kipp]

 <musing...>

I had a thought last night <careful, boss. you know you can never keep them long>
Funny, bird.

I was considering a small (relatively) little mod set in the Maze of Arrowhead (slums) using Z's fantastic Medieval City.
One of the rather, um, exotic things about Arrowhead is the presence of "Teeth" - large curved spines rising from the ground in a very precise 5km circle around Castle White. They've been there for ages (literally, 4 ages) and yet, only the locals know anything more than that they exist. <you're rambling, old man>
Hardly. Attend.

I was thinking what a cool thing it would be to hook AID into NPC dialogue. Talk to a local and choose the "What's that?" option. Your pointer turns into a targeting pointer (which makes me think this would have to use the Feat system, somehow) and you click on something that AID returns to the dialogue as a string "Bent Pillar". The NPC dialogue then branches based on what knowledge the NPC poss
esses and how much he likes the PC <pc's gold, you mean>
Whatever works.

This line of thought, of course, was inspired my Jackkal Dragon's inquiry into inquiry encounters. <i hate it when you're repeatedly redundant, wizard>

But this would allow PCs to question NPCs about local environmental objects and increase their options for interacting with the environment in a sorta object-oriented way. <he pulls these words out of his hat. really. i've seen him>
Hey. If people laugh at me, at least I made them laugh!

<...and sometimes amusing>

Modifié par Rolo Kipp, 28 octobre 2012 - 06:57 .

[henesua]

While I like what you are talking about, the heavy lifting in that scheme would not be handled by AID.The advantage of AID is that you can densely layer hidden information in an area because the stuff isn't clickable so it doesn't make the PCs life difficult when they need to click on an enemy in the middle of combat (remember attacking those old CNR trees when you were trying to click on the Owl Bear?). Plus there is the added sophistication of responding to a puzzle with natural language, rather than trying to fit every round peg into the point and click square. But ... I digress...
One solution to the problem you poise could be handled by:

• a knowledge component the PC has some knowledge data that tracks what the PC has seen that is important, and possibly what the PC knows about the things they have seen. So perhaps when discovering, examining and maybe even inspecting those teeth in AID for the first time, perhaps a journal entry related to the teeth pops up - or perhaps you simply set an integer on the PC - or both - whatever works.
• a sophisticated conversation: I think you need to use a scripted conversation here. I like Z-dialog for this reason. This is needed for the following couple items
• All NPCs have a hook which compares their knowledge about the teeth with the PC's knowledge about the teeth. If any of the various knowledge bits trip TRUE, then a potential branch (scripted) in the convo will be available. Hooks into special branches that divulge knowledge could accessed in a number of ways depending on what kind of game play you want to push:
• SOLUTION 1 (traditional):  A generic [Schmooze] gives boilerplate responses about the town unless the requisite knowledge is tripped and then a menu of related follow questions are available. [Ask about the teeth] [Gossip about the fish monger] etc....
• SOLUTION 2 (point and click): A generic [Ask about surroundings] could pause the conversation and put the character in a "cutscene select mode" as you mentioned in which the PC clicks on something nearby or near an object (and the nearest AID objects come up in a menu to selct from). Or somesuch. This would be challenging to do in a satisfying way unless you had a tight Space Quest style adventure mod.
• SOLUTION 3 (tool oriented): An [Inquire about something in your notes] option in a conversation draws up a list of items that the PC stored in a "notebook". Storing in a "notebook" would be part of AID. When you encounter an AID object, you can "note" the object, in which case it becomes another object that you store in a "notebook". You'd need to give the player an ability to manage the notebook. Perhaps the notes are an item in the PCs inventory, and you can use it to manage your notes. One of the options would be to select 9 choices that can be focused on during inquiries. If a matching key pair is found on the NPC and the AID object, then knowledge can be divulged (specific or general depending on the knowledge bits mentioned earlier, and what can be gleaned about that particular object).

So anyway, no matter how I look at this, I don't see how else one could use AID for the kind of interviewing of NPCs that you are talking about. I think the main thing is building the conversations, or a framework for conversations that can handle this sort of thing, in the right way to work with AID.

[edit: - one major weakness with AID is the way it uses tags. Tags in AID are single word names that identify the object. A barrel shoudl have the tag "barrel" so that if you want to examine it you type "examine barrel" and then the nearest object with tag "barrel" is examined. So if you have a unique object with a generic name that you want to quickly find later it becomes problematic. I think a better solution would have been to flag an object with an integer that identifies it as an AID object. Use the TAG as a unique identifier, and bury all the identifying text in local strings. This would enable sophisticated Z-machine style identification: object type (barrel), adjective + name of object type (red barrel), object + relation to another object (barrel on the rug) and so on depending on how sophisticated your object model is.... 

but anyway... i have to go]

Modifié par henesua, 28 octobre 2012 - 08:37 .

[Rolo Kipp]

<nodding...>

"cutscene select mode". I like that ;-) That was what I was thinking of.

Re: AID, I was looking at tapping into the information you are already storing under the "examine" (or similar) function to allow an NPC to acquire knowledge of their surrounding. That is, not store the info statically in a conversation, but use z-dialogue (or similar) to re-route info pulled by the NPC (with greater privileges?) from AID objects when prompted by the PC.

I.e. PC opens an inquiry with NPC. NPC offers prompt in dialogue choices "What's that all about?" and PC selects subject. NPC queries the AID info and determines what can/should be pulled and modifies dialogue to suit. But all the info is on the objects, not duplicated by every dialogue tree.

The Cutscene select is one aspect that really caught my eye. But moving the knowledgebase out of the dialogue trees and allowing NPCs to access AID info. That's more meat and less bling, I'm thinking. <hehe. sound like the dwarf>
Grrrr. Don't you be startin', bird! <*raven chuckle*>

<...in appreciation>