Library Creation
Shadowalker
17 Dec 2004, 11:41Hi. I was just wondering how I create my own library. Let's say, for example, as someone mentioned in a previous thread, I wanted a property, "Dark Room." How do I create that as a "Library Property," among other things? Basically, just how do I create a library. Thanks
Anonymous
17 Dec 2004, 12:56ebayfan414 wrote:
The basic instructions for how to create a library are included in the Quest help documentation, both online and supplied as part of the download.
However, making libraries does involve writing ASL (Adventure Scripting Language) code yourself, (you can't do it from QDK) which means that to write libraries you need to know how to program to some extent.
Al (MaDbRiT)
I was just wondering how I create my own library.
The basic instructions for how to create a library are included in the Quest help documentation, both online and supplied as part of the download.
However, making libraries does involve writing ASL (Adventure Scripting Language) code yourself, (you can't do it from QDK) which means that to write libraries you need to know how to program to some extent.
Al (MaDbRiT)
Anonymous
19 Dec 2004, 09:32Well, I don't really know asl, but I want to create my own library. So, if I want to create a command for the library, what I'm doing is creating it in qdk, then opening it up in wordpad, so I can see how it's written in asl. I don't know if you understand what I mean, but it's working for me. Anyway, I just wanted to know how I can bypass a command. For example, let's say i'm creating an object type of "moveable." So you will be able to check it off if you want to be able to take it or not. I know there is already a tab for that in qdk, but I'm just using that as an example, if I were to create another tab for beaing able to "take" an object, what is the code I use to bypass the original "take" command? Also, I added "moveable" as a type. Then I created a ball. I gave ball "moveable" type, and said that IF player TAKES object, IF OBJECT is of MOVEABLE type, then give. else....etc. It didn't work. Is that because I didn't override the built-in programming? Sorry if all this is a little unclear....thanks---ebayfan414
Anonymous
19 Dec 2004, 14:36Hi
I'm a bit puzzled as to what exactly you are asking for help with here
Firstly, a library is a completely separate file that you add to your game either from QDK or manually with the 'Include <name of lib here>.
Adding user commands is a completely different and unrelated question. You can make your own commands in a library or in Quest, it has nothing to do with libraries as such.
Your question about overriding the inbuilt 'take' doesn't actually make any sense to me, you can write your own take scripts on an object by object (or type by type) basis anyway so there isn't usually any point in messing with the inbuilt take.
What I'm saying (if it makes sense to you) is that rather than override the global take command for all objects and then have to make a test for being of a specific type every time, why not just override the 'take' for the objects of the specific type in the first place - you don't need the tests at all this way, so it is much neater (and you don't have to re-create normal take handling).
Here's an example - save the code below as 'test.asl' and run it/open it in QDK - I've used a 'take' action in a type rather than a user command - you can see how much easier this is that having to test EVERY take command the player issues
That said it is very easy to replace any of the Quest commands with your own (I do it a lot in my typelib.qlb library) and you should find you can make tests etc as you indicate. If it doesn't work you probably have either a syntax error or a logic problem - neither of which we can help you with without seeing the problem code.
Al (MaDbRiT)
I'm a bit puzzled as to what exactly you are asking for help with here
Firstly, a library is a completely separate file that you add to your game either from QDK or manually with the 'Include <name of lib here>.
Adding user commands is a completely different and unrelated question. You can make your own commands in a library or in Quest, it has nothing to do with libraries as such.
Your question about overriding the inbuilt 'take' doesn't actually make any sense to me, you can write your own take scripts on an object by object (or type by type) basis anyway so there isn't usually any point in messing with the inbuilt take.
What I'm saying (if it makes sense to you) is that rather than override the global take command for all objects and then have to make a test for being of a specific type every time, why not just override the 'take' for the objects of the specific type in the first place - you don't need the tests at all this way, so it is much neater (and you don't have to re-create normal take handling).
Here's an example - save the code below as 'test.asl' and run it/open it in QDK - I've used a 'take' action in a type rather than a user command - you can see how much easier this is that having to test EVERY take command the player issues
' "test"
' Created with QDK Pro 3.53
define game <test>
asl-version <350>
gametype singleplayer
start <start>
game author <Al (MaDbRiT)>
game info <Created with QDK Pro 3.53>
end define
define type <special>
action <take> {
msg <This is a special type object - it opened an exit when you took it.>
give <screen>
create exit south <start; secret room>
}
end define
define synonyms
end define
define room <start>
prefix <the>
look <start room>
define object <widget>
look <This is a standard Quest object>
take
prefix <a>
end define
define object <screen>
look <a tall, ornamental screen.>
prefix <a>
type <special>
end define
end define
define room <secret room>
prefix <the>
end define
define text <intro>
end define
define text <win>
end define
define text <lose>
end defineThat said it is very easy to replace any of the Quest commands with your own (I do it a lot in my typelib.qlb library) and you should find you can make tests etc as you indicate. If it doesn't work you probably have either a syntax error or a logic problem - neither of which we can help you with without seeing the problem code.
Al (MaDbRiT)
Shadowalker
20 Dec 2004, 06:32Hi there: Thanks for the help. Man the people in these forums are so helpfull!
Anyway, about libraries, I know what they are. I explained badly. What I meant to say is that in the library file I'm creating, there are some commands that I don't know. (A lot actually, since I'm new to ASL.) To see how they are written in ASL, I do it in QDK first. For example, if I don't know how to write a procedure in ASL, I write it in QDK first, and then open up that file in a word-editing program, such as wordpad. I then know how to write it in my library. I don't actually use the .ASL file...just for viewing purposes is what I meant.
I think that what you're saying is that I should add a 'take' action as part of a type, let's say, type "moveable." That's what I thought of before, only I thought that if your "take" action, let's say, gives the item to the player, but the original "Player can't take item" is checked, then that would override your "take" action.
If I'm wrong, (which I probably am) it's just that I'm inexperienced in this type of programming. I haven't tried your code yet, cause I just got on my computer, but I'm gonna try it tonight. Thanks for the help--
I think that what you're saying is that I should add a 'take' action as part of a type, let's say, type "moveable." That's what I thought of before, only I thought that if your "take" action, let's say, gives the item to the player, but the original "Player can't take item" is checked, then that would override your "take" action.
If I'm wrong, (which I probably am) it's just that I'm inexperienced in this type of programming. I haven't tried your code yet, cause I just got on my computer, but I'm gonna try it tonight. Thanks for the help--
Anonymous
20 Dec 2004, 08:55ebayfan414 wrote:
This is (IMHO) one of Quest's slightly confusing areas. There are actually four possible 'take' methods with Quest and understanding the order of precedence can make your head hurt - when are 'actions' not actions?
At the bottom of the heap is a straightforward 'take' message as typed into the QDK take message box - Quest calls this a 'tag' and it has the lowest rating. if any of the following alternatives are coded, then this take tag is ignored.
Next up is a take 'script', created if you use the 'edit script' box on the QDK take tab. This script will run instead of the simple take tag message if you provide it. It will not run if the object has a take 'action' as described next...
A take 'action' will override both a take script and a take tag, but the potential confusion doesn't end there, because Quest supports object orientated programming techniques, there are actually two ways for an object to gain a 'take' action.
1: The action can be inherited from a type. This is what I did in the example above. Here the 'action' I coded is inherited by the object(s) defined as being of the type 'special'. This action overrides any tag or script that the author provides through QDK, but is not the top of the heap, because it can be overridden by a (local to the specific object) 'action'.
2: The action can be coded in QDK under the 'add actions and properties' window for the particular obect. This action will override any inherited action (i.e. it is a specialisation) and of course also override any take tag or take script provided.
While this is a little bit complicated, it does make ASL very powerful and flexible in practice. Careful declaration of types with their inherited actions and properties makes coding variations on a theme (object wise) really very easy to do - more so because Quest supports multiple inheritance.
So, the order of precedence (from the top) is:
1: a locally coded action (specialisation)
2: an inherited action (from a type declaration)
3: a take 'script'
4: a take 'tag'
Hope this helps you get your head around the example given.
Al (MaDbRiT)
I think that what you're saying is that I should add a 'take' action as part of a type, let's say, type "moveable." That's what I thought of before, only I thought that if your "take" action, let's say, gives the item to the player, but the original "Player can't take item" is checked, then that would override your "take" action.
This is (IMHO) one of Quest's slightly confusing areas. There are actually four possible 'take' methods with Quest and understanding the order of precedence can make your head hurt - when are 'actions' not actions?
At the bottom of the heap is a straightforward 'take' message as typed into the QDK take message box - Quest calls this a 'tag' and it has the lowest rating. if any of the following alternatives are coded, then this take tag is ignored.
Next up is a take 'script', created if you use the 'edit script' box on the QDK take tab. This script will run instead of the simple take tag message if you provide it. It will not run if the object has a take 'action' as described next...
A take 'action' will override both a take script and a take tag, but the potential confusion doesn't end there, because Quest supports object orientated programming techniques, there are actually two ways for an object to gain a 'take' action.
1: The action can be inherited from a type. This is what I did in the example above. Here the 'action' I coded is inherited by the object(s) defined as being of the type 'special'. This action overrides any tag or script that the author provides through QDK, but is not the top of the heap, because it can be overridden by a (local to the specific object) 'action'.
2: The action can be coded in QDK under the 'add actions and properties' window for the particular obect. This action will override any inherited action (i.e. it is a specialisation) and of course also override any take tag or take script provided.
While this is a little bit complicated, it does make ASL very powerful and flexible in practice. Careful declaration of types with their inherited actions and properties makes coding variations on a theme (object wise) really very easy to do - more so because Quest supports multiple inheritance.
So, the order of precedence (from the top) is:
1: a locally coded action (specialisation)
2: an inherited action (from a type declaration)
3: a take 'script'
4: a take 'tag'
Hope this helps you get your head around the example given.
Al (MaDbRiT)
Shadowalker
21 Dec 2004, 21:44Hi: Thanks for all the help. Yeah, it is kinda confusing! I think I got it though. But anyway, I don't think I'll program that many "take" actions for one object, so I don't think I'll run into that problem. And thanks for the code; It worked
007bond
21 Dec 2004, 21:59Just out of interest, what is the library going to be called and what will it do?
007bond
21 Dec 2004, 21:59Just out of interest, what is the library going to be called and what will it do? And also to Al, when is TypeLib 3 going to be released?
[EDIT] Sorry for the double post, I pressed escape one second to late to enter something else
[EDIT] Sorry for the double post, I pressed escape one second to late to enter something else
Anonymous
21 Dec 2004, 22:13007Bond wrote;
It is now in (I hope) the final stages of testing after having to have a major code overhaul in the last couple of months.
When my testers stop finding bugs I've missed it will be released -
Al (MaDbRiT)
when is TypeLib 3 going to be released
It is now in (I hope) the final stages of testing after having to have a major code overhaul in the last couple of months.
When my testers stop finding bugs I've missed it will be released -
Al (MaDbRiT)
007bond
21 Dec 2004, 22:29I know how you feel. I often get my brother to test my programs. He opens it, and the first thing he does in it produces an error. In other words, he just walks in and instantly finds a problem. It's so annoying when you've just spent the last hour putting a few new features or fixing bugs, and he comes and finds another one!