Hm, well thanks for the feedback. You've given me much to think about. :twisted:

Anyway, the point of this post is to let people know that I have included the widget client in the SENTInce stream now. Like all of SENTInce, it should still be considered in development but AFAICT is stable.

To build it follow the same process as you would to build the official SENTInce-aware client (but checkout different dirs):[list=1]

• Checkout streams/neisklar/client -- this is the widget client -- and export it to wherever -- exporting doesn't copy all the hidden SVN maintenance folders, which you don't need.
• Checkout streams/SENTInce/neisklar/client and export it over the top (ie, use --force) of widget.
• Follow the normal procedure to build the client.[/list:o]
  You should now be able to use all the client features of widget and the various client enhancements of SENTInce. It'll work on main and test, but because main uses unaware scripts the NPC GUIs won't look much better than ever -- they won't look any worse, but you won't get the full effect. For that matter, the NPC scripts on test are also unaware so again you won't notice much difference to the look of things yet. But at this stage the point is to have it all work at all, regardless of client. Which it does.

What would happen if scripts were updated to be SENTInce-aware on a server not running SENTInce? Would they still work in the old way? What I am getting at, would it be OK to update scripts so they are SENTInce-ready?

The maps/lua/* scripts are 100% backwards compatible (there are a couple of backwards incompatible features which can be enabled on a per-(talk) script basis, but these are optional and off by default.

The test server has been running the aware maps/lua/* scripts for months and they seem stable.

IOW I think we could put these aware scripts on the main server without problems. Players wouldn't notice much/any difference still. The NPC's talk scripts themselves would  need updating first,but the problem here is that the NPC GUIs would look fantastic on SENTInce aware clients but unaware clients would have problems.

On the whole, I think it is desirable to keep the SENTInce aware scripts on test only for now while I continue development. Once I have some nice demo NPC scripts working on test and proper docs, we can put (think about putting) the scripts on main and then update all NPC scripts on main too.

I can't think of a situation where case is important ... I think making things case sensitive just decreases useability.  But then I'm a Window's user where C:\Temp is the same as c:\temp .



I'm not sure about improving the text parsing for the moment.  I think, as you say yourself, that good text parsing is complicated.  And the current GUI is quite simplistic really.  Long term, I can see this element of the game changing and that would then need a better parser, but for now I don't really think any changes are required.

Of course, given the topic of this thread, maybe you are saying that the improvements given by Sentince really expose the current "parsing" as inadequate?

For now, I think we should push to get Sentince and the spell/skill common modules included onto the main server (and all the main server scripts updated) - better parsing can then come later?

As always, just MO!

EDIT:  Off topic, but not worth another thread (sorry Smacky).  Hurrah!  Bought another PC at last - maybe I'll be able to spend a bit more time on Dai stuff now that I'm not fighting for PC access with the rest of my tribe!!!  And even better now that I've turned off IPv6 support in my Network settings so my net connection doesn't keep dropping off every 2 minutes (there's Vista for you )

/me points back a few posts to ToParse.


No. It is wholly adequate for SENTInce (really, SENTInce, despite its name, is not about interpreting the input so much as displaying the output).

But adequate leaves plenty of room for improvement. And here I refer the honourable gentleman to the answer I gave some moments ago.


Yes. Except before step 1 is step 0: get Smacky to finish it.

Just to make a note here, since Smacky pointed me to this thread ...

ib:SetButton("Text", "action") needs to put up a single button on the left as it did originally, and not fake a Decline button on the right as well.

I believe (since Smacky says so) that this is fixed if the user is running a SENTince-aware client, though it would be preferable if it also worked with a non-SENTince-aware client running on a SENTince server (i.e. the test server and other local servers using trunk code). Since I built both the server and client from trunk, I sort of expected they would be compatible

Well the reasoning is to reduce complexity for scripters.

The GUI supports two 'kinds' of buttons: a LHS one (accept) and a RHS one (decline).

I haven't looked at the relevant code for a while, but the current client/ib assumes that the one implies the other. So you set one and the other pops up like a disliked uncle.

This being so, the current client/ib pretends there is a third type, LHS2 (button).

This third type does not assume and is not assumed by RHS (although IIRC you can do, eg
which will do the same as:
)

So we have an API that asks the scripter to comprehend three types even though they 'map' to only two types. AFAthe playerIC there are only right and left hand side buttons. The player might not notice it, but the GUI can only have a LHS button, or a LHS and RHS button. It cannot have a RHS button on its own.

What SENTInce does is it removes this layer of abstraction from the API, taking the burden off the scripter and putting it on the client (although funnilty enough the SENTInce client code is simpler than the current client code).

Thus, the scripter only has to worry about which side the button(s) should appear on (keeping in mind that a RHS button alone is not allowed).

For backwards compatibility SENTInced IB still differentiates between SetButton, SetAccept, and SetDecline, but, essentially SetAccept and SetDecline are deprecated in favour of SetAction. So SetButton does the LHS one and SetAction does the RHS one. If no LHS button has been given, SetAction implies a default one (actually handled by the client). SetButton does not imply a default RHS button.

... I just thought of something. The behaviour I have described is not going to change, but I think I can make it fully backwards compatible. BIAB.

EDIT: No, the current client code is too inflexible. Well, it is a minor flaw -- the rogue Decline button does nothing (closes the interface), and only appears on sever which use SENTInced ib (ie, test) and when you connect with a SENTInce-unaware client. IOW use a SENTInce-aware client.

Well, I have never had a problem understanding how this works, and I guess other scripters haven't either. If you want one button, you use SetButton, and if you want two buttons (Accept/Decline, Yes/No etc.) you use SetAccept and SetDecline, knowing that you can omit the SetDecline if you want, because it's defaulted (however, only with the default 'Decline' text, and no explicit control over where it takes you).

Anyway, look forward to seeing what you come up with when you get back

I came up with nothing -- see edit.

No, it's not especially taxing on the old grey matter, but it is unnecessary. Little details like that can make the difference between people perservering with a task (in this case learning Daimonin scripting) and not bothering. Hence the change.

The current 'problem' only exists because the old client cannot handle SENTInce properly (this is one of a very few incompatibilities). Also, it only exists on the test server (and for the few devs with full access to the test server, their local servers if built with mapserv content).

Once SENTInce is released all clients will be SENTInce-aware and there won't be a problem. And we'll have that extra bit of simplicity to scripting.

@Gecko (mainly) in view of the other discussion on Lua docs in the wiki I've put my ib and tl pages, and an incomplete outline of the separation of script types that is needed (well not needed but useful to describe it) for modular scripting.

http://www.daimonin.com/Daipedia-tag-Development_Guide.html

Note that ATM I am working on other things which need to be done first, so this is just FYI. Also note that the example used in the ib doc would probably be better in qb (in that ib is not inherently linked to quests but qb is).