Well I don't :-P

I agree that "my" pages are a bit dull, but otoh they are easier to use as reference. I agree that they need to be extended with more explanations and examples, though (but that should be kept in its own section separate from the method list).

Well, all my attempts at getting the current scripts cleaned up have been shot down with the argument that "smacky is working on it". But isn't that example script from SVN, at least from a stream?

Oh I see. Doing that has never even occurred to me. I would write:

foo, bar = f()

Even if I only wanted to use bar. But I can see the readablity benefits of using _ there. But what if you are not interested in more than one variable?

I agree, and that is what I did (although given the readability point you made, perhaps this separation is not clear to anyone but me?

Anyway, yes we need to find a happy medium and then yes again, most definitely stick to it. One feature pnWikka desperately needs is inpage anchors, so you can link to a method description (for example) from else where on the page or another page. I started adding such a thing (I don't think it is too hard, although pnWikka being very beta doesn't help) but soon discovered I loathe PHP.

LOL Yeah I know. It's a slow process. Still, I should have things ready to commit to mapserv for other people to add to in 2 weeks. From there we can copy the bits to go public to SF.

And no, the example is from my HDD (well, and my backup).

Um ... just checking ... do you actually mean 2 weeks here (as in RL 2 weeks) or do you mean 2 weeks(tm)?

hehe I actually mean in between. Real 2 weeks is a reasonably likely time frame, could be earlier (not this weekend, but maybe next), could be a bit later.

A few arguments against it:
- Conventrion -- noone else does and noone have ever done it (in any language, in any project ;-) (and yes, you can probably find a counterexample, but that will just be the exception to prove the rule...)
- Consistency with the other libraries -- no other (daimonin) library does this
- Clarity -- since the parameter names also make their way out to the documentation they should be as clear as possible. The underscore does not add any information about the parameter in the function signature.
- Confusion -- There's little semantic difference between parameters and local variables, so why decorate them so prominently.

Oh, and the bikeshed should be orange-blue!

I haven't done that in lua yet, but
  _, _, foo = f()
should work

This way of using _ is (at least in my case) something I picked up from the functional language ml in my first CS year. I think it is also common in prolog and probably also in other functional languages such as erlang.
Using _foo for "private" methods and attributes is something I have picked up from lua examples and possibly also javascript. Both are languages which lack data hiding (the "private" keyword).

That's a bit harsh.

But yes, I was thinking about this stuff last night, and in view of your two other special-case uses of _ (although I'm still not totally convinced by the throwaway variable thing -- although I just read your reply posted while I was composing this, yes I guess _, _ = foo() should work), and now the confusion argument above, I think you're right.

So I'll remove the underscores from parameter names (which is a bit of a pain because I do it in all my SENTInce scripts too ).

Programming in Lua, Chapter 5.2 gives examples of using _ as a throw away variable ...

You just had to rub it in, didn't you? I've already committed the change.

General question on style/robustnes ... How important is it for a script to cope with any player input at any stage of a quest?  Or are we primarily concerned with only making sure that the clickable links and buttons on the GUI work?  I assume the former?

For instance (and I haven't tested this, only got it from reading the script so I could have it all wrong), with the example Fanrir script, if you haven't accepted any quests at all from Fanrir, and you type

/talk decline quest

Then Fanrir responds with:

"Whoah! Slow down there. You haven't even told me how you got on with the previous ^quest^."

Which doesn't really make sense.  But then, the likelyhood of a player typing this is very low, and nothing really gets broken, so does it matter?

(Apologies if I have misunderstood the script flow and this doesn't actually happen)

That is a bug then. I'll check it out on my working version.

To answer your question, yes, definitely the former. This has long been a major gripe of mine with current scripts although it is nothing to do with any technical limits of tl.lua.

The topics should always and only be triggered by plain English keywords (not proper sentences, far too much work, although see my ToParse suggestion in programmer's blogs).

SENTInce will take this concept further. Although all necessary topics will be accessible via hypertext/links/icons/buttons for some convenience and to keep the point and click brigade happy, players can and will be encouraged to use the textfield and actually type keywords or indeed use /talk <arbitrary keyword>.

For example, if an NPC offers a quest or a service (such as a smith or a priest), this must always be accessible via clicking. But rumours and background for example will be valid topics on all NPCs but will (with very few exceptions) never be available by clicking, just by typing (as they are nice additions to the immersion factor but are not vital information).

And also, if an NPC can respond to whatever keyword under one circumstance he must be able to respond to the same keyword sensibly under any circumstance. So decline quest before you've been offered any quest at all, when you've already accepted a quest but not completed it yet, when you've completed your last quest but have not yet been offered the next one, when you have completed all quests that NPC offers, and when it's actually an appropriate thing to say (ie, the NPC is offering you a quest) must always generate a sensible response.

Well - that was a bit of an effort.  I've just finished porting one of my 2-step quests to match the style shown in the example for quest builder.

At first there was quite a bit of swearing and muttering about Smacky under my breath but after a while I got used to the 'pattern' of each function call, and then it got a lot easier.

In fact, I'd have to say I agree with the approach - I've added a LOT more dialogue to the quests, and now they cope much better with players typing stuff out of order.  Previously, I just didn't add the topic for "decline quest" if the player had already accepted it - meaning the NPC would respond with a generic answer.  Now the NPC gives a more suitable response.

I found that every topic I wrote followed exactly the same pattern, and by following this pattern I was able to guarantee that there are no holes (i.e. whatever the player types, the NPC will always handle it properly).


I found this really allowed me to see everything the NPC would say, and give some consistency to each conversation.  Obviously, some conversations are valid for multiple quest states, and for some quest states the conversation can also be common across multiple quests.

Overall, it worked quite well, and I'm pleased with the result.

Some other comments relating to the Fanrir example:
+  I agree it is too long ... an example with, say, only 2 quests would be sufficient.   You could also have small additional examples that show how to use the different quest types (ITEMKILL, etc.)

+  Fanrir's script will fall down in places (I think) if you add a level requirement for the quests, as Fanrir doesn't check for QSTAT_DISALLOW, so it can't be used as a generic template for new script writers.

A final question about quest-builder.  It seems to work nicely for a linear quest series - i.e. quest A first, B second, etc.  But how would you use it if you have a NPC that has multiple quests that are independant of each other and the NPC offers them all in one go, so that the player can attempt them in any order?  Would be a much more complex set of conversations ... can you suggest an approach for this Smacky?

I'm glad it worked out for you. Yes, finding the pattern is the key. Once you've got this it suddenly becomes almost second nature and as you apply this pattern to each topic you find that the organised and consistent approach allows you to easily identify and fill 'holes' in the conversation and makes your script more maintainable and readable to others.

Well I'll probably eventually move the example quest from here: http://www.daimonin.com/Daipedia-tag-UtilityScriptInterfaceBuilder.html

Somewhere I have a second example quest which can simply be plugged in to the NPC offering this one, to show how to extend an NPC's repertoire.

The different quest types should be detailed on a page specifically dealing with this, not as part of the qb.lua docs.

I honestly can't remember the precise way it works (!) but basically QSTAT_DISALLOW is irrelevant when you use qb.lua. If a quest is disallowed, it simply won't be mentioned.

Simply, you can't do this.
No doubt people who believe the player should have total freedom will find this very poor, but the reality is to truly handle concurrent quests from a single NPC would be a bit of a nightmare. You think writing topic functions is complex now!

It also allows the map masters to plan player progress better and really the fact that quests are consecutive, not concurrent, from a single NPC has no bad effects on gameplay. Once you have enough different NPCs aiming quests at the same demographic of players it won't be an issue.

Also, you can probably cheat a bit by marking quest B from NPC 1 as completed if you do quest A from NPC 2. So the player would do A1, A2, C1...

That doesn't sound right?  So what happens if the player doesn't have the right level for the quest?  Will questnr be equal to 'nil' in this case?  I think the NPC must be able to talk to the player in all cases, and it is good for the NPC to be able to say "I have a problem, but you must come back later" ... and surely QSTAT_DISALLOW is needed for this?  Confused ...

Personally, I'm fine with this.  As you say, writing sensible NPC responses for concurrent quests will be a nightmare .