Hello again. Quick question i hope, any way was wanting to know if theres a way to change print out of the 'Default Help' command? I have searched forums and found same like topics but with no answers(that i found). Reason I ask is because I am using Pixie's custom UI script

http://textadventures.co.uk/forum/samples/topic/6456/no-longer-failing-to-customise-the-compass-rose 

and it has a custom 'Help' button which is awesome but want it to better suit my game like show a list of my commands.

Thanks for any help on this
Mike

Just create a new command with the same pattern, a regular expression like this:

^help$|^\?$

When the player types a command, Quest searches through your game from the bottom until it finds a matching command. As libraries are at the top, any command you put in will get matched in preference.

Does quest have a way to reference/use any inheritance level/layer and/or level/layer of-when over-riding occurs (if these are two separate things, lol) ???

for (a lame and pretend) example:

base quest: 'talk' Function/Command/Verb: msg ("base") // root level/layer: main parent/super

library over-riding of base quest: 'talk' Function/Command/Verb: msg ("library") // parent/super

custom over-riding of library (and also base quest obviously): 'talk' Function/Command/Verb: msg ("custom") // child/sub

is there any way I can I use/reference the library over-riding, getting/using the 'msg ("library")', and not just the custom over-riding of 'msg ("custom")' ???

and the same for the base quest, can I use/reference the base quest, getting/using the 'msg ("base"), and not the custom over-riding of 'msg ("custom")' ???

or, are we stuck with: 'talk' Function/Command/Verb ---> msg ("custom"), ????

Sadly, no.

Thanks for answering/letting me know, Pixie.

in the same ?vein?, about polymorphism and quest:

While I still don't understand polymorphism well/fully, I think it's a moot (not an) issue with quest (in whether or not quest can do polymorphism), as there's intentionally less encapsulation (which works well for quest games/making games) or that the less encapsulation is a greater use/effect of polymorphism --- meh (I said I still don't understand polymorphism that well, lol), is this correct, or am I missing some understanding/aspect of polymorphism, which makes it important for quest, even with quest's less encapsulation, and thus the question matters of whether quest can do polymorphism or not?

Thanks again Pixie you are epic, and good to know there is no override function as it's kinda what I wanted lol.
Thanks again and HK you're leaps and bounds ahead of me😀

Mike

don't worry about encapsulation/polymorphism, it's from my programming school classes, getting into the details of learning to code/program more seriously... slowly...

if interested...

(obviously a lot more to/about all this stuff, but here's a very simple/gist description)

encapsulation: is generally the use of Objects/Classes, being able to contain everything that it needs (if you've got a 'ball' Object, it can hold it's own details/content/traits/characteristics/abilities/capabilities/etc: a 'color' String Attribute, a 'throw' Script Attribute, etc etc etc, so you're not looking all over the place, everything that the 'ball' Object needs, it, itself right there has/contains/holds it all. It's basically a part of grouping/organization/specializing/compartmentalizing. An airport offers flight travel, a harbor offers shipping, a market offers food, a mathematician does math, a teacher teachs, etc etc etc),

inheritance: quest does have this to a degree at the user-friendly level (the Object Types / Types and their Inherited Attributes)

polymorphism: some thing or some action can be or do many different things.

this stuff doesn't apply too much with Quest, this stuff is more for the programming languages usage and programming, actual programming/professional level programming (software), such as how Quest was created, under-neath the user-friendly level we work at.

Polymorphism is really about being able to interact with objects without caring what type they are. In Quest, you can do this using script attributes. If you had a "death" script attribute on each object, for example, each doing something custom for that object, then you can simply do:

do(object, "death")

to invoke the script. You don't care what the object's actual implementation of "death" does (it might just print "The spider flips over on its back, and its legs curl in."), and you don't care even what object or object type it is. You can treat all objects (of that "kind" (which might be all objects that have such a script attribute) the same. And you can add new objects at any time without having to go back and change the calling code. The code becomes "closed for modification but open for extension".

I have mainly used script and delegate attributes for polymorphism in Quest. Quest internally uses polymorphism for a lot of things: think about the room "enter" and "exit" scripts, for example. The fact the "guts" of every object is hanging out for all to see (so no "data hiding") doesn't really help with wanting to have a uniform way to treat objects. By having each object handle its own logic, you can avoid all those "if (object = Wolf) do this else if (object = Red) do that" tightly coupled sections of code, where you need to explicitly list and handle each object kind everywhere you use them.

And HK, to answer your other question, there's no way to access a level of the code you've replaced. I've wished that myself on numerous occasions. I resorted once to having a "prototype" object attached to the derived object so that I could explicitly call the overridden functions from the base type.

Ah okay, so there's really not too much use for polymorphism for users of quest, if I'm understanding you Jay, as the open/global/public nature of quest's OBJECTS (Elements) and its Data/Content/Methods/members (Attributes), which is wonderful for making quest games unlike in normal programming where such global/public variables/objects-classes/etc is generally a very bad practice, makes polymorphism a bit of a moot point (as polymorphism is for the most part about allowing such global/public/open usage without actually have an open/global/public structure/design; aka polymorphism allows encapsulation to be public in terms of usage but-while keeping the actual encapsulation structure in place --- If I understand polymorphmis --- I was just wondering if there's anything else that polymorphism can do which would be useful in/for quest, and then if such polymorphism could be done in quest), I was just wondering if there's any aspect of polymorphism that could be of use in quest, and then whether quest can thus do polymorphism or not for that aspect of polymorphism that quest's open-ness/global-ness of its Objects doesn't nullify.

(Definately underneath, polymorphism makes quest into the wonderful engine that it is --- Alex and co have done an amazing job --- quest is really so user-friendly-seemless, I'm really amazed at how well quest is built --- they really created a such great amazing engine! --- I'm just talking about the user-level of quest in whether there's any uses for polymorphism, and if so, if quest can do that type of polymorphism or not)

I was just trying to describe 'polymorphism' and encapsulation' in layman's terms for the non-programmers in my previous post, without getting into their real/full aspects/usage, which are much more technical/complex, as they're not familiar/learned in programming like us who know some (or a lot/all/most of) programming (early stages:me or expert:Jay, Pixie, Pertex, etc).

and, that's very a creative solution! having an Object contain Objects for their 'parent/root/super classes and their members/methods/etc'

Actually, that's not what I said. :) You can use polymorphism anywhere you can attach functions to objects that you can reference by name, but where the function invoked is different for each object based on that name. It's about pushing the handling of objects into the objects themselves rather than having it by the higher-level code. Something like this:

if (object = "apple") {
   msg("The apple tastes good!")
} else if (object = "banana") {
  msg("Yuck, I hate bananas!"
} else if (object = "grape") {
   msg("I'll save this to make some wine.")
} 
etc

is called "simulated polymorphism", because rather than handing off control to the object, you're peering into the object itself and deciding what to do. It would be better to have a script attribute on each object and move the various implementations into the objects themselves (where the call at the top level becomes "do (object, "eat")" or whatever you want to call it. Then the calling code doesn't have to care what the object is - the object handles it.

And there's plenty of room and support for this in Quest. As I said, I have used it, and the core code uses it. Those were meant to be two examples showing it's a viable approach in Quest.

ah okay, thanks for explaining, as I wrongly generalized my understanding of polymorphism as being able to bypass the encapsulation without removing the actual encapsulation (for example: a derived Object acting as and/or using a parent Object and its members/methods, aka a 'magicbox' Object/Class acting as its parent 'plainbox' Object/Class from my text book example, lol), as this is what my limited understanding of polymorphism is, as I still struggle a bit with it, obviously sighs, and in/with understanding it and its implementations/applications.