A fully SENTInced house_seller.lua is now in streams/SENTInce and on test.

It's turned out well IMO. It shows how NPCs who offer services should explain those services (except where they're obvious, like in bank.lua) and (I suppose) require confirmation before taking the player's money (although I agree with the seller on this point) -- in any case, because of the NL way in which SENTInce expects input players can easily bypass all that nonsense by prefixing their commands with 'confirm '.

Eventually I would like to make confirmation a togglable optiion, but I'm unsure of the best way to do this just now.

EDIT: Corrected some issues with bank.lua (just textual) and house_seller.lua (I had forgotten to edit the pasted topic_background(), topic_quest(), and topic_rumours() from bank.lua and forgotten to put it some rather important text in greeting to lead the player to services).

ib:ShowSENTInce() and tl:CheckMessage now handle actions in a (hopefully) slightly enhanced way.

Although I don't think this feature has ever been used, topics can take a table of strings and/or functions as an action. Then each action is performed one by one, with functions doing whatever they do and strings being SayTo()'d the player.

This is fine as far as it goes, but there are two significant drawbacks:
[list=1]

• The script has no real control over the performance of this list; all actions are performed no matter what; and
• SayTo() doesn't make much sense with the NPC GUI as the interface obscures the chat window.[/list:o]
  
  This enhancement (which is experimental, although it seems to work from my brief testing, there are a couple of things with which I'm not entirely happy) solves these issues by causing tl:CheckMessaage() to return different values based on the action in question. ib:ShowSENTInce() then picks up on this and acts appropriately.
  [list=1]
• Function actions may return nil (the default, ie, no return), false, or a value. If they return a value tl:CheckMessage() converts this to true. If the return is nil, we just carry on traversing the list of actions as normal. If it is not nil (ie, true or false) we return this value, thus terminating traversal. [* I am not sure I've understood Lua's handling of returns though *]
• String actions by default get SayTo()'d the player and return true. If a (SENTInce-only) argument to tl:CheckMessage() is true nothing visible happens and the string itself is returned. Thus a string action will always terminate traversal of the list of actions.[/list:o]
  ib:ShowSENTInce() then handles these returns in the following ways:
  
  • nil (the default) or false -- the interface is built and displayed as normal.
  • true -- any existing interface is closed (for example because a message has just been SayTo()'d the player).
  • string -- the string is printed in the interface, along with a Hello action button. Thus you can handle unrecognised topics sensibly by, eg tl:SetDefault("What?").
  With luck this will mean that old scripts which have a string action will not change behaviour (ie, the SayTo() the string, but don't close the interface. tl:Checkmessage() will return true but this return is thrown away. The change would be that now traversal of the action list is terminated whereas before it wasn't. But as note, as no-one seems to have used multiple actions anyway this should make no practical difference.

A fully SENTInced church.lua is now in streams/SENTInce and on test.

Note that this initial version is pretty identical to the old one in what it actually does, ie, casting prayer on the player. For example it willl happily take the player's money for remove death sickness even if the player has no actual death sickness. This is so that players can fairly compare SENTInce with the old stuff. The Sh priest still uses the old script. The Sg priest uses the SENTInce one.

Note also that I haven't writte the explanations yet because I am lazy.

In fact there are a few things, but these are all easy tweaks and additions. The point ATM is to get a solid SENTInce base.

EDIT: BTW players may notice some oddities about NPC name in SENTInce scripts. This is actually because their name attributes haven't always been set very sensibly in the map files. SENTInce merely highlights these flaws. Easy to fix those map files.

A little earlier I moved all the qb stuff out of gh_fanrir.lua and into it's own quest_builder.lua (qb).

qb is a layer on top of questmanager which allows individual talk scripts to very easily build up their own list of quests on offer. You can then deal with the current quest easily and sensibly. Adding a new quest to the NPC is trivial.

For example, gh_fanrir.lua is:


Now questnr is set to the number of the next/current quest -- eg, 3 for "Mouse Hunt" -- or nil if all quests are complete. So say we want to find out that status of the current quest, we just query qb[questnr].status (I will probably wrap this in a method) (EDIT: Done -- qb:GetStatus(nr)).

If we want Fanrir to offer a fourth quest, just stick in a new qb:AddQuest() in the appropriate place.

Anyway, as with the rest of SENTInce I'll write proper user docs later, but for now this is the latest stage of development. All commented and available in streams/SENTInce and on the test server.

I've committed a few changes to SENTInce.

The most important one is that scripters can now specify a number of items (+ or -) to be displayed in an icon -- the bg colour reflects the signing and the number is superimposed over the image, as with coins.

This required a few little changes to the client, so I have created client/ in stream/SENTInce/ which will contain any modified files (currently src/event.c, src/interface.c, and src/include/interface.h). To compile a SENTInce-aware client is easy. Checkout the normal branches/0.9/client or trunk/client, and then copy streams/SENTInce/client over the top of it, thhen build as normal.

HOWEVER, you needn't do any of this. The SENTInce scripts will all work fine with just a normal client. You just won't get red (they're all green) bgs on the icons or numbers.

I started modularising SENTInce now. What does this mean?

For example, church.lua can cast various prayers on the player. So we define a table of castable prayers and their costs at the beginning of the script. Then in the function which handlels casting we read this table, looking for a match with the prayer the player has requested. When we find it, we require modules/cast_prayer and call the function contained within with the name and cost from the table. The module then handles charging the player and casting the prayer, returning a flag indicating success or failure and a string saying exactly what happened to church.lua. church.lua can then do as it sees fit with this string and/or print its own guff.

It's on test but shouldn't make any difference to players. But scripts using modules will be smaller and (hopefully) easier to read and write and maintain, and smaller..

good job smacky, when i get time to, i will see how easy/hard this is to do for a novice!

=)

Yay! My run of double-posts is broken!

Well bear in mind that it is in dev and (apart from comments) undocumented. The module stuff, for example, is just a test version ATM. The next version -- probably finished over the weekend -- should make writing a 'normal' talk script very easy and should put an end to the 'generic' scripts in scripts/.

But yes, someone other than me trying it out would be very helpful.

It's nice to see the modular approach as discussed put into action.  If it's easy enough, I might even get to learn doing scripts (when I'm not sifting through the server code).  heehee

Yes, the version I'm working on should be pretty close to what was requested in that thread.

im back! im confused beyond belief in this thread as of now

if you can tell me specifically how i may help, i would be glad to again

~missy

@Sub: hehe This thread will be very confusing. SENTInce will not.

The point of this thread is that I am developing completely in public. This: (a) possibly will prevent people from claiming I haven't consulted or taken other opinions into account -- although probably that will still be argued :roll:; and (b) might give some of the armchair developers some insight into why development can't happen over night (and keep in mind that SENTInce is not the most difficult thing in the world to develop, though nor is it the easiest [maintaining backwards compatibility while adding meaningful new features is a bit tricky]). The flipside of public development is that everyone gets to see my experiments and tests and learning curve, which can make it appear confusing and haphazard. But take my word for it, I have a very clear and definite goal in mind.

So it's in everyone's interests if you (as in anyone) does follow and contribute to this thread and gives input, but if you can't, you can't. No problem.

It'd be very helpful if players could test out scripts on the test server (as you already did). Fanrir is SENTInced. The Stoneglow priest, bankers, and apt seller are SENTInced ATM.

alright then after im done checking the forums i will go check out those NPC's for you

~missy

EDIT: i tested the NPC's you listed and i noticed that the text seems to be more organized i especially like how instead of giving you all the options you must click services instead

the NPC's are working fine in other words good job

Exactly. This is such an important concept. It make interaction quicker and easier and more consistent and intuitive for players and influences the way in which scripters write scripts, making them faster and easier to develop, write, read, and maintain.

To counter balance this 'organisation' it is also possible always (previously it sometimes was, sometimes wasn't) to type in a natural English phrase to directly get a particular result.

For example, rather than

/talk hi
(click services)
(click the cast cure disease link)

just do

/talk cure disease

(To be fair this was one of the cases where it was already possible so is maybe not a great example )

A better example might be the quest handling (as seen in Fanrir).

Now in streams/SENTInce and on test is the very latest version of a modularised SENTInce script.

I got a bit bored so the comments haven;t been reworked yet, and the last few additions are a bit hacky (in particular the module needs to support ib better -- not difficult but I didn't think of it until this morning).

So what does it do?

Well from a player's POV it should make going to the priest more entertaining and more explanatory for new players. I won't describe SENTInce again. You can ask Sahrus (only the Sg priest has this now, all others use the old script so you can compare) to explain any spell that he can cast or teach and he will do so. When he casts a spell you get a little description of him casting it and you are shown how many coins it cost you graphically.

From a scripter's POV it makes writing NPCs who can cast spells a doddle.

The old church.lua script was : http://daimonin.svn.sourceforge.net/viewvc/daimonin/branches/0.9/maps/scripts/church.lua?revision=2517&view=markup

The SENTInce version (which is now stoneglow/sahrus.lua) is : http://daimonin.svn.sourceforge.net/viewvc/daimonin/streams/SENTInce/maps/planes/demon_plane/stoneglow/sahrus.lua?revision=2605&view=markup

That may not give a fair compariison as the SENTInce one has a lot of comments and more features. So here is an example which, while not fully SENTInce compliant, does everything the old script does:

So you can probably see that with such modularisation it makes sense to write scripts for individual NPCs rather than a generic 'church' script, etc. Which means that each NPC can have its own particular character.

Anyway, as I think I said above, there a some rough edges still which I'll smooth out over the next few days. Then I can write some more modules and demonstrate how a multi-purpose NPC can be scripted pretty effortlessly by combining modules. Plus use quest_builder to handle quests and you'll have a really nice NPC with (comparatively -- you still need to have some idea of how to use Lua) little effort and a script of no more than 300 lines (most of which are text).