Hmm. I agree that SENTince should rigorously check with asserts. Better to catch scripting errors up front so the scripter finds out. Was I being lazy only supplying two parameters to AddIcon? I don't know. I imagine I got that from somewhere.

Hmm. Doing a search of all lua files, looks like a prima facie case of mea culpa.

Except for: endar.lua and tavern.lua which also have this error (endar has an explicit nil third param and tavern.lua has a 2 param call)

That is pretty much it (except that I wouldn't go so far as to call it a 'script fixer'.


Well in building the GUI command everything is necessarily converted to a string anyway so it is just a question of whether it is sensible to allow the scripter to, say, use objects as parameters and then quietly tostring() them somewhere in ib (sometimes it is and both SENTInce and old ib do this in places) or complain bitterly because while it would be very easy to quietly tostring() anything the fact that a scripter has used a, eg, boolean parameter rather than tostring()ing it himself possibly indicates that he is expecting behaviour other than a quiet tostring()ing and a failure/warning is useful as it alerts him that he has tried to do something nonsensical.

If, and TBH I am skeptical that this is ever going to be genuinely useful for 'minigames' and such, the scripter really means, eg,


it is perfectly easy to do


instead.

So the flexibility exists. It's just that it is not the ib function's job to perform arbitrary type conversion. Lua has other functions for this task where necessary (and other features, and sometimes it is not necessary anyway).


Yes, currently scripts should be written for the current client and current ib.

A few unofficial scripts (ie, Nao's) do the 2 param thing whereas others (ie, Sammy's) use an explicit empty string as the third.

No scripters are at fault here. This is the problem of allowing arbitrary 'typeless' parameters and having no checks or warnings. Flexible but messy, and a pain when it comes to future expansion -- for all its short term flexibility, it's actually restrictive in the long term (there's a big difference between creative and disorganised)

Yes, but that might take a bit longer - initial priority will be to quickly review 53 scripts and just get them working.  They can then be upgraded to take advantage of the new features at a more leisurely pace (I'm happy to help with this).

If scripts don't get what they need in terms of parameters and so produce garbage, then they definitely need error checking/assert statements.

Of course the challenge is to try to think of how someone might want to do something in 1 years time and plan ahead for it ... but more easily said than done!

Thanks. I'll hold you to that!

Actually it is really not that difficult to SENTInce-ise scripts. TBH mostly it is a matter of deleting 10-50% of the script.

You then add that and more back in the form of comments (not strictly anything to do with SENTInce but just good practice/good for newbie scripters to read).

Also, unavoidably, several contributers maintaining scripts bit by bit over a few months/years has led to them becoming somewhat fractured and disjointed, hence the real need for rewrites. I think I have disabled the main incompatibilities (besides this assert() stuff for example) while the official/widget client is SENTInce-unaware.

ATM I am writing some Lua modules. These basically perform 2 tasks:[list=1]

• They contain all the basic details about a certain subject so scripts can reference these details and players get a consistent and more realised gameworld (for example, all the spell descriptions in the screenies I've been posting are from the spells module).
• They wrap up common and possibly complex features in library functions so scripters can access these functions easily. For example, the following function from the SENTInced church.lua (not yet released) teaches the player any prayer which the priest knows (it is easy to disallow/allow specific prayers to be taught, and also each prayer has a price [a standard price which can be tailored to a specific NPC] and the specific script could easily incorporate other checks, such as a level req [in the current implementation, everything is free, and with no restrictions, for testing]):
  Code:
  [/li][/list]
  local function topic_serviceTeachPrayer(_prayer)
      require("modules/skills")
      if not module_skillsKnow("Divine Prayers") then
           ib:SetMsg("Hm, you do not know the ~Divine Prayers~ skill necessary for casting prayers.")
      else
          local message = module_spellsTeach(_prayer)
          if not message then
              ib:SetMsg("I can teach you nothing more about ~" .. _prayer .. "~.")
          else
              ib:SetMsg("|** " .. priest.name .. " begins to instruct you in divine knowledge **|\n")
              ib:AddMsg("\n" .. message)
              ib:AddIcon(string.capitalize(string.split(_prayer)), module_spellsGetIcon(_prayer), "|** " .. priest.name .. " teaches " .. string.capitalize(string.split(_prayer)) .. " to you **|", 0)
          end
      end
      ib:SetAction("Services")
  end
  [/list:o]
  
  Now I am half expecting to reach some limit on the total script size or number of scripts running concurrently. But I'll deal with that hole when I come to it. Luckily modules aren't absolutely critical to SENTInce.
  
  Many modules basically do the same thing as each other, but in their given area of expertise. Eg, spells and skills.
  
  My question is, which is preferable:[list=1]
  
• Function names accurate to the specific module. Eg, module_spellsCast() and module_skillsUse().
• Generic function names. Eg, module_spellsDo() and module_skillsDo().[/list:o]
  
  The module_fooKnow() function will probably get a name change to module_fooIsKnown(), the idea being that module_fooIs...() functions all check a specified foo against a player object. This brings up another example of the above. In the deities module we want to query the which god the player follows. So do we handle this with module_deitiesIsKnown() or, ie, module_deitiesIsFollower()? There is also an afflictions module (depletion, drain, etc): module_afflictionsIsKnown() or, eg, module_afflictionsIsSuffering()?

.......how do idownload this? its all so confusing soo many words and links and stuff....simplyfy it plz

I don't really like 2 ...

e.g. learning a spell, vs. asking for it to be cast ...

module_spellsCast('Cure Poison')
modeul_spellsTeach('Cure Poison')

... its obvious what those 2 function calls do.  But ...

module_spellsDo('cure poison')

What does that do - cast or learn?  Or are you saying you would need an additional parameter?

module_spellsDo('cast', 'cure poison')
module_spellsDo('teach', 'cure poison')

Hmmm ... maybe that would be better, now that I look at it ...

Or, alternatively - "Torchwood has completely missed Smacky's point" ???

Good idea though!

I prefer IsFollower('deity') to IsKnown ... sure I might know about the Tabernacle, but am I a true follower - there's a difference.  Same with IsSuffering.  These are 'conditions' of a sort, where as spells are knowledge (so IsKnown is more appropriate).

@Jeffy, yeah it'll be/seem complex ATM because it is still in development. However, I think I have now (apart from tweaks and bugs of course) finished the client change, and the maps/lua/ scripts seem robust. IOW the basic SENTInce is finished.

I am nearly finished the first demo script (a rewrite/expansion of the general priest script).

Once this is done I'll put it on the test server and give a step-by-step guide to building a SENTInce-aware client (both official and widget) and hopefully someone can prepare some Windows executable packages so players can test it out properly (SENTInce-aware clients will also work without problems on main).

The current questions, about modules and such, are only of interest to scripters and are not vital to SENTInce itself.

@Torch: having slept on it, I'm a bit more determined in what I think is the correct approach:

I think Cast() and Teach() are clearer, less complex and therefore less likely to generate errors (and shorter to write!) than Do('cast) and Do('teach').. Also, the more modules you have, the more confusing and strained generic Do() functions become.

Similar arguments for IsFollower(), etc vs IsKnown(). IOW I agree with you (although perhaps a generic IsKnown() would in fact be named IsFocus() -- even more generic and meaningless).

Another question for scripter preference.

Each of the four modules existing so far has an IsKnown() (or equivalent) function: module_afflictionsIsSuffering(), module_deitiesIsFollower(), module_skillsIsKnown(), and module_spellsIsKnown().

Each function takes two arguments: _foo (ie, a specific affliction, deity, skill, or spell) and _player (a player).

The idea is simply to check if _player 'has' _foo, returning _foo's object or true (for concepts such as spells which are not object-based) if he does and nil or false if he doesn't.

However, it would also be useful in all cases to allow _foo to be nil. In this instance the return is a list of objects or strings which _player 'has'. Eg, { skillobj1, skillobj2, skillobj3 } for skills or { "Probe, "Magic Bullet", "Firestorm" } for spells.

This is easy to do and building and returning the necessary table is a doddle.

But in the case of module_deitiesIsFollower() _player will only ever be the follower of one deity. So wrapping the string in a table is unnecessary. However, for consistency with other modules, should it return a table anyway?

Hmmm ... question ... how do you know that in the fullness of time, Daimonin won't be expanded to allow more than one deity to be followed?  After all, the Ancient Egyptians and Romans certainly weren't single-god civilisations, so there is some precedent ...

So, my vote would be for string wrapping in all cases (besides, I like consistency - neater that way ).  Scripters are going to have to learn how to deal with a table of strings in anycase, so dealing with a table of just one string is no real hassle.

Just my 2c.

I don't know. But as far as I know from how the system works now it is only one deity at a time.

But yes, I agree with you.

Even Romans & Greeks had a prefered gods/goddesses to worship.  I would say perhaps a person can follow one primary god/goddess, but have a few that you have knowledge enough of to cast minor cantrips in the name of them if needed... and in the sense you would have to have a table to express that knowledge

I am now looking at a couple of ways to improve the efficiency and success rate of sending and matching the player's input to a topic.

Topic parsing is a simple keyword (or phrase) comparison. No complex sentence structure analysis or NLP here. There are many reasons for this, including:

• it is really hard and work-intensive to write and perform NLP -- neither of which are justified by the needs of the Daimonin talk interface.
  
• it is much more complex for the individual scripter to write topic lists which cope with a NLP.

So, bearing a bit of realism in mind, please consider these point:[list=1]

• Is there any real need to be case-sensitive in parsing talk messages? ATM the player may enter input in whatever combination of case he likes. Internally, the input is converted to lower case before any 'parsing'. Can anyone envisage a (realistic) scenario where case sensitivity is important?
• Should articles (a, an, the) and extraneous whitespace be included in the input to be parsed? For example, ATM 'the tabernacle' is considered totally different input to 'tabernacle', although of course they are in fact the same. Multiple whitespaces between the and tabernacle can be ignored/treated as only one. Can anyone envisage a (realistic) scenario where article/multiple whitespace is important? (We can make an exception for, eg, input of just an article like 'the' or more likely 'a' so that the server doesn't just receive a confusing empty string).[/list:o]
  What I am thinking in both cases is to process the player's input client-side, so before it is sent to the server. This has two main advantages:[list=1]
  
• Efficieny of the server -- while this processing could be done in Lua (ie, server-side) it is (a minute bit) faster to do it in C and of course removes that work from the server entirely.
  
• Efficiency of the data transfer -- of course this only applies to the article/whitespace suppression. If we strip out articles/extraneous whitespace, before the command is sent obviously less data needs to be transferred.[/list:o]
  But one disadvantage:[list=1]
  
• Because processing is done client-side, the server never sees the exact input as entered by the player. There is no way to get this exact data to the server.[/list:o]
  IMO, the advantages easily outweigh the disadvantage (which is only a potential problem anyway). This is the same as parsing input in a text adventure.
  
  But, anyone got another point?

I keep being distracted by other things, and feedback seems a little nonexistant on this one. A few things occur to me:

• Removing articles client-side is actually no good, as there are too many exceptions: /ready_spell (although that is a client command), all chat commands, and /talk itself. /talk because SENTInce by default displays the topic (what the player typed) as the title of the GUI. This should indeed be what the player typed (not counting extra whitespace and capitalisation I think -- see below), so including articles.

However, I still think articles are dead weight when it comes to topic matching. In fact, checking for them makes it more difficult for the scripter. So lets send them to the server, so they are included in the GUI title but delete them from the topic when it comes to matching.

• (See ToParse) This also raises a question over pronouns. Sometimes pronouns can also be ignored. For example, 'give me the sword' could have the pronoun (me) and article (the) removed without its meaning suffering: 'give sword'. But equally, 'give the sword to me' could lose pronoun, article, and preposition (to). But if the topic is 'give my sword to him' the two pronouns are important, so it's not a simple matter. Rather, this level of topic processing requires quite a complex parser. As mentioned above, this would need to be done server side (well it could be done client side -- for example, the client could encapsulate 'useless' words in non-printable chars -- in this way they could still be displayed (the words not the chars) in the GUI but could be ignored by the topic matching -- however this would slightly increase the amount of data being transferred: 'give ®the® sword ®to me®'.
  
  At this stage punctuation also becomes interesting... You see where this is going. A full client-side parser for /talk topics a la those found in text adventures may be a useful addition, making NPC interaction via the GUI much more satisfying and powerful.
  
  However, this is a big job, probably enough to warrant its own separate development stream.
  
  
• Removing extra, leading, and trailing whitespace, client-side, for all commands seems sound. As does lowercasing all commands except those which reference filenames (just '/goto <map>', '/resetmap <map>', and '/restart <stream>' on Test, I think). However, being client-side, the server wouldn't know if this had been done or not, so it's really just a player convenience, not an absolute safeguard or anything.