2 Requests are in here for the QDK


1) Rename Object Type

When I "Edit" an "Object Type", I would like to be able to rename the object type.

For example. I initially created a type "Door", which had a property for determining if the door was opened or closed and a property to determine if it was locked or unlocked. It also had actions for opening/closing the object it was attached to and actions for locking/unlocking the object.

I decided to separate this into two generic types (Openable and Lockable) so that every door didn't necessarily have lock functionality and so that I don't have to manually tell the QDK to ignore ("NOT") certain properties/actions.

I would have preferred to rename the object type to openable via the QDK rather than creating a new object type.

Since openable is not really a word, I may wish to change the name again later.


2) Auto fill / remove properties and actions from objects with a given object type and editing default value for the given object.

When I select an object type or types for a game object, I would like the QDK to visually display the properties and actions 'inherited' in the window. This would be good for reference and I could then 'not' properties and actions if I wanted to not include them. Along with this might come a 3rd feature request that would allow me to enter the initial state of each property as I select them (via the same interface already there for the Properties tab with the "value" text box).

I hope this makes sense. I'm just learning to use this system and trying to figure out how to organize the finer points and create some re-useable types/scripts.

Types are a collection of properties which are inherited upon the point of assignment... Ie, they don't really exist until the code comes to that point and the object is given the default properties defined in the type...

This is important because - picking specific values from a type would suggest that you are taking a specific 'type' (say, red clothes) and trying to generalize them (any colour clothes for instance).

It's more idealistic to create a general type (clothes) and then specific sub-types through inheritance (clothes, of which are socks... Which are red)..

So you could have one specific type (red socks) or 3 types which you can each give to the object (clothes/red/socks).
- I think that's what you were trying to do with question 2?

Maybe I'm misunderstanding here but I think we're talking in different directions and I'm positive I wasn't very clear in my description.

Example of what I'm saying:
NOTE: I realize this is an incomplete example


LOCKABLE TYPE
1) Select Game Menu
2) Select Object Types Menu
3) Click Add
4) Type Lockable
5) Under properties tab, Add name:is_locked and value:false
6) Under Actions tab, Add lock and pretend there is a script
7) Under Action tab, Add unlock and pretend there is a script
8) Click OK button


OPENABLE TYPE
1) Select Game Menu
2) Select Object Types Menu
3) Click Add
4) Type Openable
5) Under properties tab, Add name:is_open and value:false
6) Under Actions tab, Add close and pretend there is a script
7) Under Action tab, Add open and pretend there is a script
8) Click OK button


OBJECT IN ROOM
1) Create A Room: Room 1
2) Create A Door: Door 1
3) Select Door 1
4) Click the Advanced Tab
5) Click Edit Properties and Actions button
- NOTE: No properties or actions currently
6) In Properties and Actions Dialog select Types Tab
7) Press Add and select Type: Openable
8) Press Add and select Type: Lockable

NOTE that if you click on properties and/or actions, none are listed unless you add them.

WHAT I WOULD LIKE TO SEE, is the 'inherited' properties from the added types to automatically be filled in at this level for reference and in the event I want to overwrite them or 'Not' them via the interface.

In the end, I changed my directions and started creating a library instead because I prefer editing a library file for the scripts and I can create a tab interface on the main screen. However, I still think this could be useful to those that depend on the script editor and Types Dialog.

Erm, so you'd like to be able to edit types through objects instead of actually editing the types?
.... But how would you then know whether you're editing a type and not the object itself?

(sorry, headache, my brain is both active and trying to avoid thinking - quite amusing)

*deep breath*...right, first things first..

You create types (I wouldn't actually create an openable type myself, as door's that don't open sure aren't doors, and what's the point of locking/unlocking something if you can't open it!?).

Now, when you are in QDK and creating the game, assigning a type doesn't just change the object to have those properties/actions. It simply adds a "type <>" line into the object code.
Once the object is created by Quest (the game-player) then the type's default properties and actions are given to the object - so it's run-time.

If you wanted to "not" a property provided by the type, then you simply create the not property... But I do see your point in the fact you need to go find out the correct property.

Perhaps having them a faded colour or something similar.. I've never quite liked QDK.

Yeah. I found QDK quite difficult to work with too, ll those new windows to edit stuff and much harder to see the bigger picture of what you're doing. Coding as ASL is much easier nd simpler, though I sometimes get QDK to create the game file sometimes as I can never remember all the define game settings you should use. lolz.

Tr0n wrote:
Now, when you are in QDK and creating the game, assigning a type doesn't just change the object to have those properties/actions. It simply adds a "type <>" line into the object code.
Once the object is created by Quest (the game-player) then the type's default properties and actions are given to the object - so it's run-time.

If you wanted to "not" a property provided by the type, then you simply create the not property... But I do see your point in the fact you need to go find out the correct property.

Perhaps having them a faded colour or something similar

Heh. Yeah, a faded color might be good to show it's inherited from at type.

The type interface basically allows you to override or overload properties and actions so if you overrode it, then it wouldn't be faded anymore.

Tr0n wrote:
You create types (I wouldn't actually create an openable type myself, as door's that don't open sure aren't doors, and what's the point of locking/unlocking something if you can't open it!?).

It's for reusability. Doors are not the only openable items. Bags, Chests, Windows, You mouth, etc etc. The basic openable functionality simply includes properties to determine if the created object is open or not and actions to open/close the object.

You can even include code within the actions (open/close) to see if the object is Lockable too and that knows it can't open if it is locked. However, not all doors, chests, etc need a lock state. And potentially there could be some type of object where it needs a lock state and it's not openable. So, tying locked to open or vice versa is assuming much and potentially causing to duplicate code on another object type.

I am starting to create an ASL/Quest library based on the Tads 3 object model, which I personally think is very nice. If I can successfully (albeit slowly) do this over time then I get the best of both worlds.

Tr0n wrote:
I've never quite liked QDK.

I personally like the QDK as a visual interface but don't like like using the script builder (which is why I moved to libraries that allow you to visually add what you need). However, there are plenty of non-programmers that probably would depend on the script builder since there aren't libraries available to do everything they need.

I suppose in the end, it would be great to have a huge library (ie: Tads 3) and not need the object type interface at all.

cangelo wrote:I am starting to create an ASL/Quest library based on the Tads 3 object model, which I personally think is very nice. If I can successfully (albeit slowly) do this over time then I get the best of both worlds.

You'd be very hard pressed to do that; ASL is a clumsy language and not well suited to the task.

Assembly languages usually have a rigid syntax that is easy for machines to parse, but requires breaking things into small steps. Higher level languages (usually context-free grammars) are harder for machines to parse, but work in a more convenient step size. ASL has the small step size of assembly, but has the difficult parsing of an HLL.

The more "static" languages (that do all the work at compile time), like C, have very extensive error checking. More "dynamic" languages like LISP have the added power of closures, macros, and run-time code evaluation, at a cost of being able to verify less at load/compile time. Quest has even less error-checking than the dynamic languages, without the corresponding power.

I won't go into the horrible design of the object model or of qsg.

You can even include code within the actions (open/close) to see if the object is Lockable too and that knows it can't open if it is locked. However, not all doors, chests, etc need a lock state. And potentially there could be some type of object where it needs a lock state and it's not openable. So, tying locked to open or vice versa is assuming much and potentially causing to duplicate code on another object type.

What I'm trying to say, is that instead of assigning, say, 3 types to the door, you can have one type (door) which inherits the other 3 types, and only have to give the door one type, etc.

I did start work on a couple of things, but found I kept running into blocked walls.. I can't remember where I left off..