I didn't for one moment think it was an English problem, just a typo, since you spelt it correctly (several times) in the rest of your post

I'm thinking something along these lines:
- Fix ib:SetAccept(label, command) and ib:SetDecline(label, command) to make the "command" parameter optional (defaults to the value of label if not given).
   Rationale: this is a good idea in any case, and both trivial and backwards-compatible.
- Add a ib:SetActionButton(label, command) function which basically sets up the "accept" and "decline" buttons the way a "return cmd,txt" does now.
   Rationale: this follows the ib API by using an explicit method call, and keeps the tl and ib APIs separate. It also allows us to use the return values from tl topic functions for future tl-related things. (PS. The method name is just an example. I'm sure you can figure out something more fitting).
- Skip the "close interface if using SayTo on a  default string behaviour"
  Rationale: I don't like that a tl call has side effects on the interface. Also, if a conversation was started in the interface, it should end in the interface - not with a SayTo(). This also means that the topics that have strings as actions shouldn't be available through interface links (or alternatively, should always use the interface instead of SayTo()).



I disagree strongly that the return system would be more extensible. The idea with explicit method calls is that we can always add more and/or alternative methods, while there is only one return from each function.

I have one big issue with the way SENTience currently is implemented:
Adding a "Topic: " prefix to every title is both redundant and intrusive on scripts that don't want to use the interface for SENTience chat scripts. The same goes for forcing the header to the name of the person you are talking to.
A method like "ib:SetDefaultLayout()" or something similar would let us keep the current flexibility - it could even take be "ib:SetDefaultLayout(label, command)" and also set up the buttons like the proposed "ib:SetActionButton(label, command)"

My point is that SENTience conformance should not be enforced, but should be activated through a simple method call (or alternatively by a parameter to the ib constructor, or even through a separate ib constructor as in "ib = ChatInterface()" or something similar).

OK, yes the 'what about strings (as opposed to functions) as actions' question was going to be my next argument against using a method instead of returns. But if we deprecate strings as actions this problem should go away. However we need to retain allowances for them for backwards compatibility. Something in the back of my mind is jumping up and down and shouting 'look at me!' though. I'll have to think about this a bit, but yes unless/until I can identify this possible problem I'll accept you proposals.


OK, again unless/until I can figure out my suspicion I'll go with this.


One of us is misunderstanding the other. It is a point of SENTInce that it, both the style guide, and the codey bit, is not mandatory or enforced. While I (obviously) think all but the most abnormal talk scripts should use SENTInce in its entirety they don't have to. That's why preserving backwards compatibility was /is a big design goal. You can copy the SENTInce-ised maps/lua/* scripts over and non-SENTInce talk scripts will continue to work fine (if you find problems, let me know).

ib:ShowInterface() is ib:SetDefaultLayout(). It sets up the header, title, and buttons in the standard SENTInce way -- if you don't like it simply don't call it (then calling ib:SetHeader(), ib:SetTitle(), ib:SetAccept(), ib:SetDecline(), and obj:Interface() is once again completely on you/your script. You're still free to use as much or as little of the style guide as you like, and you can use the tl.synonyms or not as you like.


Well again, if you don't like these, don't call ib:ShowInterface() (maybe the generic name is causing confusion -- ib:ShowSENTInce() ?

IMO these are both very important from an informational UI POV.

Notwithstanding the bit above about SENTInce not being enforced, it's main purpose is to bring consistency, simplicity, and useability to talk scripts. IMO current talk scripts don't have these. If we encourage scripters to customise their SENTInce-compliant interfaces too much (by providing specific methods for this purpose)then compliance becomes a relative term, SENTInce becomes self-defeating, consistency goes out the window, and we're back to square one. Players lose out because of scripters' vanity.

Well, I still think they may still have a place as a standard greeting if the NPC has nothing else to say (instead of opening up the interface for a boilerplate boring response).



My mistake. I got confused over the ib:ShowInterface() call and thought that was also the old way of opening the interface.



I totally agree with you here. (although I'm not as convinced that SENTInce is the ultimate dialogue system - but it sure beats the existing scripts and the UI consistency is important)



Again, I agree with you. Not following the standard layout/guidlines/SENTInce should be reserved for extreme cases (and yes, I have a few in mind ;-).

Well, with the misunderstandings and flaming cleared up, I'd like to get back to a couple of technical details...

First, keeping the Topiclist (tl) and Interfacebuilder (ib) APIs separate and independent on each other has high priority for me. The current Topiclist survived the transition from the old SayTo() frontend to the new Interface() GUI without much changes. By keeping it separate we avoid locking it up to another system which may or may not be with us in the future. Likewise, it will be easier to attach another "backend" to InterfaceBuilder() if it doesn't depend on anything from Topiclist.

Second, and not really as important to me, is keeping InterfaceBuilder clean from any layouts. InterfaceBuilder does a great job being a simplified frontend for the Interface() method. SENTInce is another abstraction layer on top of that, and I feel that it should work best as a subclass of InterfaceBuilder. That way you can add a few SENTInce-specific methods, deprecate those that shouldn't be used with SENTInce, and it is obvious from the object instantiation that this isn't a "raw" InterfaceBuilder interface. Heck, it could even integrate TopicList =).
A small example (not syntactically correct, just trying to show the principle here) on how that could be used (just brainstorming here...):


(ok, integrating tl in SENTInce is probably overkill - but it saved like 2.5 lines of code ;-) )

The idea is that InterfaceBuilder can be kept clean of high-level functionality and layout concerns, while SENTIence can disable the possibly confusing methods that it doesn't need (like SetDecline(), SetAccept(), Build() etc).

Yes, you're right. I spoke in haste. I'll be able to think about all this at my usual liesurely pace on Saturday.


So perhaps a rename (ie, to ib:ShowSENTInce() or something is in order if we don't go down the route you suggest below of having a SENTInce module -- immediately I'm not so keen on this as I'll briefly explain below)?


I definitely don't think it is the ultimate system. It is intended to be (and I think functionally, if not totally ideally (yet) successfully) an improvement building on the current ib/tl system -- it should get the best end result with the minimum change so scripters (and players) don't need to learn another way to handle player-NPC comms. As I say I have gone to some lengths to retain full backwards compatibility. Of course this means that in some ways I am stuck with some of the 'flaws' (I don't really mean that, but I can't think of the right word) of the old/current/established system.


LOL I do think that some of the style guide is more important than other tips. For example, the tips about staying to <2000 characters per page (for bw reasons) and the tip about non-indented paragraphs with a single line separating one from the next should IMO always be followed.


LOL Actually, I'm going to go to bed soon instead of explaining my objection to a SENTInce module ATM.

But as to keeping ib and tl separate and the fact that SENTInce is another layer of abstraction (in fact originally I did not want to touch ib at all) I agree very much.

I'll return to this over the weekend.

Just made the following changes. I must admit it is a better approach. I will look more at the strings as actions issue after lunch.



EDIT: that thid one should read:

** They cope if one of title/face is not given and the one that is given is a GameObject -- so you can do, eg, ib:SetHeader(obj) and get a decent result.

Yes, but the problem is that this is incompatible with the way SENTInce works (if we use methods and not returns, as we now do).

This is becasue onlt tl knows the type of the action. ib doesn't. So with returns I could examine type(action[1]) in tl:_DoAction() and then call activator:Interface(-1) in ib:ShowSENTInce() if it was a string (basically).

But now because tl and ib have no interaction I can't examine the type.

Because one of the 'features' of SENTInce is that you need only a single call to ib:ShowSENTInce() at the end of your script you will get an empty interface on a string action, which is obviously no good.

Two ways round this are:
[list=1]

• Basically go for a hybrid of a return and a method system so that tl:CheckMessage() returns type(action[1]). Then pass this return as a second argument to ib:ShowSENTInce() and at the start of that function have:

That's kind of ugly though and of course doesn't keep ib and tl as separate as discussed above.

Perhaps to resolve that issue (so idealistically) require the type-check in the actual talk script:


Goes against my simplicity design aim though.

• Don't have ib:ShowSENTInce() at the end of the script, but have it at the end of every topic_foo function.

Very much not my intention and goes against the simplicity aim again.[/list:o]

EDIT: Having slept on it, I think I'll implement the first first solution. That is, tl:CheckMessages() returns the type of the action and this is passed as a second argument to ib:ShowSENTInce(). Thus at the end of your script you have:


ib and tl are still separate from each other, and using SENTInce is not made more complicated.

If anyone has a major issue with this and a better way to do it, post, otherwise I'll commit in a while.

EDIT 2: Hm, possibly we need an extension to obj:Interface()...

Have it return true or false to indicate whether or not an interface for obj is open, and add a mode 0 which only reads (thus returns) the current status of the interface for obj.

Therefore, if mode == 1 it opens a new interface, if mode == -1 it closes any current interface, and if mode == 0 it simply returns the open (true) or closed (flase) ness of the interface (for consistency it always returns but obviously this will always be true for mode 1 and always false for mode -1).

The reason for this is that if we have tl:SetDefault("WTF? Idiot, talk sense.") then if the player walks up to the NPC and says 'dfsjh' we want him to do a SayTo. However if halfway though an interface conversation and the player types 'fgdh' we want the default reply to be written in the interface. So we need to be able to query the open/closedness of the interface (which I don't think we can yet?)

You may or may not be interested that I've just wikied the style guide: http://www.daimonin.net/?op=modload&name=phpWiki&file=index&pagename=SENTInceStyleGuide

It isn't linked into the rest of the wiki yet (while SENTInce is still in development).

In lieu of the other post, and presuming who = Smacky, I didn't make it suck, I have introduced various improvements. The problem is everyone is still writing their talk scripts in the sucky old way. I mean we have a few quest script ingame which even have the bit telling the player what the quest status is! Huh?

I did underestimate how difficult it is to get people to change their habits. In fairness this is partly my fault for not providing enough documentation. The Sarah script I am doing should go a long way to fixing that.

It's really not about text-based vs. GUI. The GUI is fine and necessary, but developers need to remember that it is merely a frontend. Underlying it is a text system. As such you need to write to that text system. Daimonin itself then has the job of automatically converting to the GUI. Don't write for the GUI directly. If you do that your efforts won't work properly/except as a point and click interface.

The scripty bit of SENTInce fixes the technical side of this but even with the old interface_builder/topic_list, you can use the SENTInce style guide and write much more useable, flexible, and expandable scripts -- check out the Sarah script ATM for a small example (although it is more obvious with the quest, etc stuff which I haven't finished yet.

All this single-link-at-the-bottom-of-an-interface and 'checkq1' stuff is all well and good if you want the interface to only be usable as a point and click interface and you have no desire for your scripts to be expandable in any sensible way.

Well I didn't have time to make the other post, so maybe there is no need now (though I don't want to go too much off-topic).


So where is this? I looked in the Documentation Wiki under Mapmaking/Scripting and in the scripting forum, but couldn't find it.

OK - searching in another tab shows up a post "SENTInce example script", but in the Release Dev forum, where it isn't public, and it's not even a Sticky.


I was going to ask if there was any way to stop labels appearing in the bottom window when they are not wanted. Plus I want my "Your reward:" back - at least as an option. I don't see any problem with point and click for a simple talk interface - it is a GUI after all - and I am not sure what you mean by expansion.

Edit: I just checked the quest templates to see if they had been updated to the guidelines, but they haven't.

Fair point. I've moved these posts from the Rosie thread to the SENTInce one.


No, the link is three posts above. It's not in the official docs because it's not official yet. There are still a few things to sort out, such as writing service offering scripts (which I have nearly done -- working on Sarah, Korae, and the modular stuff I've done has been very useful here). It's only going to cause massive confusion if I publically release it before it's ready/I've even convinced the B4 mappers to use it...


Same reasons as above.


Well re expansion. For example, someone decides to add a quest to a service-offering script (such as has been done with GH smith). ATM this is a small to medium technical hassle and the result makes very little gameplay sense/looks a bit (lot) rubbish. Or someone some day adds another quest to Cashin -- again possible, but not easy and chances are the resulting script won't be too readable (or will be a total rewrite). Or in the future, someone adds some more storyline/new topics to Rosie. Probably doable (I haven't looked at Rosie's script) but I'm guessing the script has not been written with this possibility in mind. Certainly other scripts haven't been.

As for the 'Your reward:' thing, the problem is if you include this as mandatory (as the client used to) icons (and more importantly selectable icons and coins) are no use for anything other than rewards. For example, it looks much better to have a menu of selectable icons in a repair script rather than a list of textual links -- it's a case of 'we're using a GUI so how about we make it graphical and not textual' -- but still useable by textual/keyb means. Or using coin icons to visually show how much money you have just spent/received or deposited/withdrawn or what your balance is.

Now due to the way interface_builder/the interface itself works and the need for backwards compatibility, I don't think it is possible to make this optional in any sensible way... Hm, I suppose it would be possible to jigger about with interface_builder.lua/interface.c to encapsulate the icon/coin blocks in an explicit reward block if specified (interface.c already refers to all that as a reward block which can be a bit confusing).

But none of that is practical until the autoupdater is ready because it involves changes to the client.


Again, no they haven't. However streams/SENTInce/maps/dev/testmaps/quests/quest_normal.lua is (but its fairly old and undocumented).

Might be helpful to sticky this thread? Or at least a new post with the link.

I think it is important that certain keywords have universal meaning, hence the SENTInce standard topics. Thus (currently):

So you type such a word, and you are assumed to be talking about the given standard topic. Obviously this concept of standard topics needs to be explained to players beforehand. That is it's point -- so that players can easily probe an NPC on the four most important, general topics without the dialogue writer having to put unnatural words and phrases into the interface.

This imposes some restrictions on individual topic_lists; they must all recognise the standard keywords as links to the standard topic, else the idea falls apart.

Therefore, no pulling a Bruce Willis and calling an NPC Rumor, as when the player type rumor he will be assumed to be asking about rumours and not trying to discuss Rumor.

A question though, should "job" be a synonym for quest (I want to add "work" too)? It could equally be a synonym for background, depending on whether the player is thinking to ask 'tell me about the job/work you are doing' or 'do you have a job/work for me?'. A solution might be to delete it from the standard topic synonyms altogether, though personally I think this would not be good. I'm inclined to keep it as a synonym for quest, but thought I'd try and drum up some interest here.

I make that twelve words you have to include in every script for background.  How about choosing just one well-known word for each (well, maybe not for greeting) which is explained to every player. So a player will know to say "quest" to any NPC to check if there is a quest available for example.

Well the number of words won't put more work on the scripter as the entire table is included with one method call (or ATM unpack).

But of course more synonyms = more restricted words.

Yes, just one word (plus incorrect spellings and plurals where appropriate) would be fine. So:

greetings, hello, hey, hi -- 4 here, special case
quest
rumours?, rumors?
background
services? -- not a standard topic for all NPCs, just for those offering services, so a non-standard standard

(Services isn't mentioned in the wiki yet -- I'm still developing a generic yet sane way to handle these -- think I've got it now).

Actually this is better I think. Although it means this information will have to be easily accessible to all players (noobs anyway) at all times. -- for example perhaps Fanrir's first quest could be to read his book -- which details this -- rather than examine his shoes.