I've just realised that QDK allows "Out to" as a direction but seems not to allow "In to".
Since many adventures start outside a building or cave, is this an oversight or is it me talking through my armpits?

Frank

Now there's a man who can think
I reckon that that would be a good idea. I think we all liked the up and down directions come into ASL 350. How about ASL 400, with an into function, plus at least some of the ideas in my list of needs, and some more built-in commands.

007Bond remarked

and some more built-in commands.

I don't necessarily agree with the idea of more built-in commands. I have been working with TADS in which most of the commands are in libraries. This makes them very easy to adapt and change. Quest has excellent libraries and I think that's the way to go.

Frank

EagleWing wrote::? I've just realised that QDK allows "Out to" as a direction but seems not to allow "In to".
Since many adventures start outside a building or cave, is this an oversight or is it me talking through my armpits?

Frank

I like this idea. They had the "into" command on Dark Legacy.

Although this is *possible* in Quest (a custom command and a place, so the user could type "go in to #room#" or "go to #room#") I think it would be much nicer to have a "in <>" part to the room definition block too.

Good eye there Eaglewing! I guess it's just something that people don't use right away (I hadn't even thought of it up until now).

007 - stop thinking as if any of your suggestions are intelligent.

Frank (Eaglewing) wrote:-

I don't necessarily agree with the idea of more built-in commands. I have been working with TADS in which most of the commands are in libraries. This makes them very easy to adapt and change. Quest has excellent libraries and I think that's the way to go

Yep, that's the way I see it too, once you really try something like TADS or INFORM you appreciate just why they are the way they are in having most functionality in libraries - it is quite simply a better (more flexible) approach.

In fact one of the big improvements touted by TADS 3 over TADS 2.x is the fact that even more of the functionality (basically everything!) is now provided as libraries rather than having anything much hard-coded.

On my soapbox here once again - but I have to repeat that if the accepted 'benchmarks' of IF design think libraries are the way to go, I think it is as well to take notice.

Here there is a problem with Quest though - one I can't see an easy user workaround for.

I've built a whole library of often used verbs and objects, there are literally hundreds of them as I based this on an expanded version of the ALAN system stub library verbs. Now this works fine for me when coded by hand in ASL - I can add the library and all is well - 'luvverly jubbly'.

However if I try to make an easy use Q.D.K. Interface for 'stubs.qlb' as I call it (in the style of 'typelib.qlb'), I end up with a nightmare - I need to add dozens upon dozens of tabbed panes to the Q.D.K. interface. Roughly 1 tab for every two verbs in fact - YIKES!

My only suggestion here is to ask Alex nicely if we can have a library-writers funtion that allows us to add things like this to a list-box. Then we'd have to be able to 'attach' scripts and property check otions etc to only be available with related items in the listbox.

I've mocked up a visual impression of what I mean by this :





My idea is that as the end user drops down a choice in the list box, the whole 'options frame' is populated with options related to the choice. This whole thing to be tailorable by library writers rather in the way we can add tabs now.

The basic idea is that it would avoid having dozens and dozens of tabs added by a single library:-)

Any thoughts?

Al (MaDbRiT)

Looks like a good idea but it would be a bit of a pain to implement. I'll take a look into what can be done though, but you may have to wait a while...

Alex wrote:

Looks like a good idea but it would be a bit of a pain to implement.

Oh yes indeedy, I can well imagine it would be a right royal p.i.t.a. to implement - but on the other hand it would be a very slick and effective solution to the 'too many tabs' headache if it could be done.

You know I like to set you these "little challenges" now and again Alex

I'll take a look into what can be done though, but you may have to wait a while

Personally I can progress what I want to do with Quest without this feature so I am not in a tearing hurry, but it would be nice to see this from the point of view of QDK users sometime soon.

Al (MaDbRiT)

Madbrit said

My only suggestion here is to ask Alex nicely if we can have a library-writers funtion that allows us to add things like this to a list-box. Then we'd have to be able to 'attach' scripts and property check otions etc to only be available with related items in the listbox. . . . My idea is that as the end user drops down a choice in the list box, the whole 'options frame' is populated with options related to the choice. This whole thing to be tailorable by library writers rather in the way we can add tabs now.

The basic idea is that it would avoid having dozens and dozens of tabs added by a single library:-)

Sounds brilliant to me.

BTW how near is "stubs" to being available (if only in ASL)?

Frank

I like the look of the stubs library. it's a good idea.

and CW, have you ever tried to be nice to someone, or is that beyond you?

I'm not the one being angry at someone because of their lack of punctuation.

I get angry because of the lack of intelligence. As you can properly see, you were thinking you should be on a king's chair - when you should be in a "high-chair".

Frank wrote:

BTW how near is "stubs" to being available (if only in ASL)?

Not even close. To be honest I've never really even considered releasing it at all because it can't be sensibly made to work with QDK under the current limitations of library interfacing.

As a result it is completely undocumented and not exactly elegantly written and arranged. I can use it 'cause I wrote it, to let it loose on anyone else would almost certainly invite a mass of usage problems

I don't even want to think about the confusion the 'shipboard' movement directions it includes (for a very specific piece I did) would cause to everyone else - (you move 'forrad', 'aft', 'starb'd', 'port', 'below' and 'aloft' etc.) - LOL

Also I think Alex would prefer any libraries that get released be ones that integrate fully with Q.D.K. - ease of use IS the Quest guiding principle after all.

Al (MaDbRiT)

well then just make it not usable with QDK. I'm sure you might miss out on a few downloads, but it's still gonna help.

007Bond muttered

well then just make it not usable with QDK. I'm sure you might miss out on a few downloads, but it's still gonna help.

Did you read what Al said? Al said,

Also I think Alex would prefer any libraries that get released be ones that integrate fully with Q.D.K. - ease of use IS the Quest guiding principle after all.

Now I'm as keen to see some of that library as you are but if Al wishes to co-operate with Alex by NOT releasing libraries that don't integrate with the QDK we are obliged to respect his decision.

Al - any chance of releasing smaller libraries based on part of your mammoth work that maybe will fit QDK? Just a thought - pleeease!

Frank