that sounds wonderful! I love reading what a NPC has to say (and in B3 there was a big lack in that) B4 is much more refreshing!

and last time i went to check on the NPC's SENTInce'd, i thought they had a very well done organized chat that was more interactive (instead of giving you all the options right off the bat [great example is the priest])

i will go have a chat with Mr.Sahrus right now :p

~missy

Quick update on the last week and a half:

• I have been working on a complete SENTInce-ing, tidying, and quest-expansion of Guild Hall. This will make it more interesting and offers newbs a lot more help, making it much easier to get into the game. As a result, I have removed the previous SENTInced Fanrir script from the test server. It served its purpose. The expansion won't be ready for another two weeks. Currently it only exists on my HD (plus a back-up).
  
• I have slightly tidied the spells module and just added an initial skills module. This is basically a mirror of the spells module, but dealing with skills. So in the same way as they explain, cast, and teach spells using the former module, NPCs can explain, use, and teach skills using the latter. This is all available in streams/SENTInce/ and might even work (not tested yet).
• I have made various tweaks, bugfixes, and imptovements to the core SENTInce scripts (the ones in lua/) and scripts/church.lua.

(This thread was getting a bit quiet. Oo! I know, seeing as things aren't even on test, I'll move it to Programmer's blogs so it looks as if the devteam is actually doing something -- we don't really. )

Smacky - is there an easy way to test out the new NPC scripts on the test server without having to download and recompile the latest client from /trunk (or where ever)?

ATM yes and no. I think I removed all new talk scripts from test (as it makes no sense to have them there until I've finished my GH expansion -- testing to date has already proved that the theory behind them is sound).

However, the core of SENTInce (the scripts in lua/) has been on test for several weeks so anyone logging in with any client whatsoever is already using it. So far there are no problems (reported anyway). I can see no reason why there should be problems, as the server is still sending the client exactly the same data.

Unexcitingly, what you should be getting from test is exactly the same as what you get from main on a SENTInce-unaware client. A SENTInce-aware client will give youo the same again but with a couple of conveniences (eg, a few more keyboard shortcuts like HOME and END to go to the top or bottom of an interface).

I now have the GH expansion about 50% done and have turned my attention back to the client. When I've finished updating that SENTInce-aware clients will handle the data received from the server in a slightly different way (some of the data I should say). This means again that NPC GUIs on SENTInce-aware clients will look and feel better and be more useable than on unaware clients. That means aware = gain but unaware != loss.

I think I just need to complete one more change to the client (the way it handles keywords) and then I can get back to GH and the scripts in scripts/.

So to answer your question ATM testing on test is largely a moot point. Whichever client version you use should be (and AFAIK is) irrelevant. You can of course checkout streams/SENTInce/maps and export that over your local dir. The main point of this would be to test the modules stuff as used in scripts/church.lua (but read the comments at the start of that file first -- IIRC you'll need to edit the script data of the priest first or he won't actually do anything). Also note that while the modules should do what they do without problems, there is more to come, so chances are I already know about 'module X doesn't do Y, it should.'

SENTInce is in a fairly unexciting state ATM. It all works, but the focus right now is on it working the same as old-style interfaces.

Finally, because this has come up on IRC, the client changes in streams/SENTInce/client will only work on official clients (trunk or branches should make no difference). They can not be directly applied to Alderan's widget client (although as said, widget will work like any other SENTInce unaware client). The reason for this is that Alderan and I are developing independently and have both modified the same source files. However, when I am done it will be a simple matter to merge SENTInce into widget (in the same way as merging it into trunk). Only Alderan and I will need to worry about this.

What does GH expansion entail (so mappers are aware)? If you are developing maps away from the SVN, then we don't want to be treading on toes (claws?) or anything.

Sure. Just don't touch GH. I know that by saying don't do it that will only instill a desperate need in some people (no Grommit, not you) to do it, but try to resist the urge, as it was resisted for several months until now.

I have everything up to and including the travel agent, and will update for bugfixes to that (although the map side of it should be stable I think, the script side does not affect my changes). But I'm not going to update if other people start fiddling around with what's already on SVN.

The only surface maps I am claiming are castle_020a to castle_050a, and possibly castle_030b (with one or two new maps east and south of that if I do what I'm considering).

( Everyone must read this entire post. You may need to take the day off work/school/gaming to do so. )

Here's some fruit of my recent labours reworking the way the interface handles icons. This is from the SENTInced and module-using church.lua (that script wouldn't actually be used ingame). This version isn't actually uploaded yet (still needs a bit of spit and polish).

First a quick explanation.

SENTInce comprises three elements. Well in good Daimonin style it is really 2 +1.

1 is the script-technical side. This is lua/interface_builder.lua, lua/topic_list.lua, lua/quest_manager.lua, and lua/quest_builder.lua. The first three of these are just reimplementations of the existing APIs. While they (in particular ib) have a few new and expanded methods, everything is 100% backward compatible. Old scripts which pre-date SENTInce work fine with these new implementations. The last one, qb, is a replacement for qm (which was a replacement for qc ).

2 is the SENTInce Style Guide. I haven't updated this in a while. There are a couple of bits that need a rewrite, but it is basically sound.

1 and 2 are both entirely optional (well, you have to use the reimplementations in 1 but can just use the old familiar calls if you're feeling conservative) and independent of each other. That said, the intention is that everyone fully embrace SENTInce as consistency is important.

The +1 is the client side. ATM, during development, this is slightly complex as there are three clients. First is the official client (trunk or branches or download does not matter) and second is Alderan's widget client. These are both SENTInce-unaware. SENTInce will work fine with them but won't look as good and you may get red FixMe messages from time to time. Second is the SENTInce-aware client. To compile this you need to get the source for the official client (trunk definitely works, branches should work, and download might work) then copy the contents of streams/SENTInce/client over it and build the end result as normal. Alderan's client cannot (easily) be made SENTInce-aware at this time. When SENTInce development is over we can merge (or reimplement if my code is too horrible) my changes with his.

So the +1 should be thought of as mandatory in that, when SENTInce development is complete scripters can assume that players will be using a SENTInce-aware client (auto-updater would ensure this) or rather scripters will not need to think about this at all. However, during development the +1 cannot be considered mandatory as many players can't won't build the SENTInce-aware client.

Hence the need for SENTInce options. SENTInce options turn on/off specific SENTInce features for individual players. The purpose of this is twofold.

Firstly, it enables players with SENTInce-unaware clients to only view the features of which their client is capable. For example, a SENTInce-aware client can wrap up to three lines of body text per icon and allows more text as well. A SENTInce-unaware client cannot wrap text. Therefore player using the former turn the SENTInce option use icons on (by default it is off) and hey presto! instead of nasty text links they get icon eyecandy.

SENTInce options have to be set per character not per player (ie, server-side not client-side) as the server needs to know which data to send to the client (AFAIK the server cannot quickly query a client) so these cannot be added to the client options.

Secondly, and more importantly in the long-run, it enables players some control over the way their interface looks/acts. This is best explained by example (BTW the quick explanation is over now ).

By default (ie, use icons OFF) the priest gives his services in a menu of links. This renders exactly the same in both aware and unaware clients:

Aware: http://www.daimonin.net/modules.php?set_albumName=album08&id=aware_false&op=modload&name=gallery&file=index&include=view_photo.php

Unaware: http://www.daimonin.net/modules.php?set_albumName=album08&id=unaware_false&op=modload&name=gallery&file=index&include=view_photo.php

With use icons ON the list of services is given in icon format. Here, the unaware client cannot really cope, although no vital information is lost. It just doesn't look good:

Aware: http://www.daimonin.net/modules.php?set_albumName=album08&id=aware_true&op=modload&name=gallery&file=index&include=view_photo.php

Unaware: http://www.daimonin.net/modules.php?set_albumName=album08&id=unaware_true&op=modload&name=gallery&file=index&include=view_photo.php

Notice the different action (RHS) button in either pair of pics.

In the link pics it is Explain, which will take you to a new 'page' of the same links (except instead of 'Cast foo on me' they read 'Explain foo to me'. Now when you select a link you simply get an explanation of the service (in this case what the spell does).

In the icon pics the explanations are already there so the button is Choose. You select an icon then click Choose.

In both cases you can always type in 'explain <spell>'.

Now both styles have (dis)advantages over the other.

Links:

• Less text = less bw. (Not sure if this is any sort of advantage for slower connections but it is probably nice for the server host).
• Less text = everything fits in the window with no scrolling needed.
• SENTInce aware clients can select and execute the first 9 links on a page with a single keystroke. Any client can select and execute a link with a single mouseclick.
• 2 executions to get an explanation per spell and when you're in explanation mode, one more execution to get back to 'do' mode and then another one to actually 'do'.
  
• However if you don't need explanations (only newbies will) it is just a one-click deal to 'do'.
• Overall faster and more utilitarian but/therefore not so pretty.

Icons:

• More text = more bw. The style guide recommends an upper limit of 2000 characters of text per 'page'. Scripters should factor in the image names (ie, "si_111" = 6 characters). ib:Build() then adds a few more characters before sending the data to the client. This example comes to 1410 characters all told, so is well within the upper limit.
• More text = scrolling. SENTInce-aware client can go to the top/bottom of an interface with HOME/END and I hope to make the client automatically scroll the interface when you TAB through keywords/links or cycle through icons.
  
• The explanations are all right there.
• But it is a two execution process to 'do' anything (select the right icon, click Choose).
• Overall prettier and nicer for newbies but perhaps not the choice of the busy modern gamer on the run. Lets do lunch.

This is why there are SENTInce options. Another use for these is quest hints. For example, some NPCs give you a |Hint| when they send you on a quest. Players can turn use hints ON or OFF depending on how the feel about 'spoilers' (bona fide spoilers will not be found ingame, not ever).

Comments?

(darn web site ... logged me out right in the middle of typing my reply ... lets try again ...)

Interesting post Smacky ... some comments:



I totally agree that options are a good thing for the future - improves no end the players experience if it allows single click actions, etc.  These days, as a touch typist, I just type "/talk deposit all" when talking to the banker - much quicker than clicking through the menus!

However, I'm not sure about the development bit?  I'm not sure about your comment:



This is only true if there is no vital information in the first part of the description??  If someone develops an NPC script using SCENTInce, and doesn't test it using the official client then there could be problems, with information missing from the GUI.

I think it is important - especially for the noob experience - that everything on the main server hangs together properly ... so no red FixMe messages or missing text from GUIs.

The obvious thing is to get the auto-updater working ... easy for me to say, but I've heard nothing on the forums about this for ages - perhaps someone can start a new thread and explain status?

Once the auto-updater is working then we can assume all official clients are SCENTInce aware and we should then be able to move forward with adding SCENTInce scripts to the main server maps.

(Or maybe I didn't really understand the problems you were explaining  : :lol:)

Having just written some quest scripts, and struggled with getting the correct logic flow such that the NPC always make sense no matter what the player types at any quest stage, I'm really looking forward to SCENTInce going live ... but no way could I cope with developing a script that works well with SCENTInce aware / unaware clients all together ... it's got to be all or nothing

I think you got the point even if you didn't realise it Torchwood.


Indeed, and this it hints at the third immediate use for SENTInce options. It seems that everyone constantly needs to confirm every little decision they make (annoying as it is I guess this is slightly justifiable when a single misclick of a button can have catastrophic effects).

In terms of SENTInce, the services topics work so that if you, say, make a large transaction (one where you actually gain/lose something, not a bank deposit) you are then told what you have said to do and asked to confirm it.

While that may be necessary for general use I personally find it highly annoying to have to repeat myself. If I screw up, well that'll teach me to be more careful in future.

So we have a SENTInce option, confirmation (defaults to ON). People like me can turn it OFF.

Oh, before I get too carried away with myself, currently SENTInce options are not handled  automatically. That is, the talk script reads the options manually and then acts accordingly. For example, church.lua is:

Which isn't ideal (especially when options can interacf). I should be able to fit the options in to ib, but inevitably at the cost of flexibility. So it is weighing up the pros and cons.


True. This is where the Style Guide comes in. For example, keywords. SENTInce allows keywords in the body text of icons (unaware clients do not). Therefore if the keyword is vital it will break the script on unaware clients. However, the Style Guide will (it doesn't yet IIRC) specify that keywords are not for vital information -- they are simply conveniences for mouse/TAB jockeys. For that matter, icon text is not for vital information either, for the reason given above.


This won't be a problem as by the time people besides me a developing scripts usiing SENTInce it will be part of the official client (don't you love my confidence? ).


Indeed. I refer the honorable gentleman to the answer I gave some moments ago.


Yes the auto-updater is very important to the future development of the client (and as noted elsewhere, indirectly to scripts).

I think I've seen the solution but it requires a few additions to ib.lua and some changes to the client code and then I'm not quite sure about backwards compatibility (ie, how unaware clients will handle such scripts). So it'll take a couple of days to implement.

Well this definitely wouldn'r be backwards compatible in the sense given.

Meaning the unaware clients would complain 'INVALID GUI COMMAND' and not render the interface at all. However, aware clients (in conjunction with scripters who choose to use this feature -- again it is not compulsory) would offer players a (IMO) significant enhancement.

So this means that during development of SENTInce unaware clients would 'fall over' (they wouoldn't crash) at scripts which used this feature. But after development all clients would be aware so the distinction is irrelevant.

Therefore it's only a problem during development. I see two ways round this. Firstly -- and this is the realistic workaround I think -- I include both the code above and the nice efficient code (commented out) in scripts during development, so that all players can at least use SENTInce (seeing as I'm commandeering test this is important) and then remove the nasty code post-development. Secondly, I say screw you unaware clients.

Yes, the first is the wway to go.

Language Smacky - I'll have to /mute you if you're not careful

How about - how can easily you create a new SCENTInce aware client.exe?  Could you recompile a client.exe and put it up somewhere so that those who can't/won't* get into all the SVN/recompiling stuff can still get involved in SCENTInce testing?  Or is this unfeasible?



* i.e. me!  I will get into this SVN/compiling stuff soon, but not just right now! :lol:

If someone suffering through Windows has a compiler and would like to do this they're more than welcome. Compiling SENTInce is no harder than compiling the normal client.

It turns out that in one way this is simple but in another it presents problems and in a third it is impossible. I'll explain.

The NPC GUI has three selectable elements:[list=1]

• keywords;
• links; and
• icons.[/list:o]
  
  These are navigable/selectable in two differnt ways (by keyboard, mouse is irrelevant here as with a mouse you already must have scrolled the window to make a selection):[list=1]
  
• keywords and links are selected with TAB/sTAB (in SENTInce aware clients 1-9 also work for links but we can forget about that here); and
• icons are selected with UP/DOWN.[/list:o]
  
  On top of that, they are rendered, without going into details, according to two different methods:[list=1]
  
• keywords use one method; and
• links and icons use the other.[/list:o]
  
  Due to the method used by keywords if the keyword ^foo^ is selected all keywords ^foo^ on that page will be rendered as selected (as a matter of style scripters shouldn't do this anyway, but the fact is it is doable). It is not possible to make keywords use the same rendering method as links/icons.
  
  All this means that it is impossible to make the window scroll when the user selects a keyword.
  
  It is possible to make the window scroll when the user selects an icon (my local client does it, although I still need to tweak the calculations).
  
  It should therefore be a very similar process to make the window scroll when the user selects a link. Except that I suspect this would lead to a lot of user confusion:
  • Why does the window scroll for links but not keywords when they both use the same selection method (TAB)?
  • What about pages with both icons and links? Do we scroll for both (ie, whichever is the most recent selection) or prefer one over the other (In fact this issue could be resolved with another client option -- let the user decide)?
  So due to the way icon selection works (execution is on pressing a button only) I think it is best to avoid these issues and only scroll for icons.
  
  But from the user (player) perspective, is something better than nothing (ie, icons only) or is it all or nothing (which will mean nothing)?

Tough one Smacky - really not sure.  Consistency of UI is very important (which leads to all || nothing == nothing) ... but extra functionality is good as well!

People tend to get used to things quite quickly, so for the expert player, as long as they can do what they want quickly then they probably don't care.  However, for noobs it is different - these are people who are not 100% sure what they are doing, and also are people who aren't committed to the game yet.  I think if they see inconsistent / part finished behaviour it will be another factor to put them off the game.  So, I think my vote goes to "nothing".