Some of you might remember me talking about a game that I was writing, which would have a whole list of things that I think needed fixing, upgrading, renewing, putting in. Well seeing as I ain't gonna be finishing that game anytime soon (damn homework), I decided I would just release the list anyway. Here it is for you to speculate over.

Built-In Commands I would like to use in my game:

Hold
Play
Read (Script and Standard)
Take All and Drop All
These are just built-in commands I would like to use in my game. There are plenty more I would like to see implemented.

Other things I would like to see implemented or changed:

1. A conversation system. If Alex Warren (the designer of Quest) can write a text parser, I'm sure he can write a basic conversation system. For someone like Alex, I'm sure it would be easy. Look at the BASIC program Eliza (Email me @ [email protected]om and I'll send you a copy).
2. Less Windows in QDK: If I want to add a Print Command inside a Then script inside a conditional script in a Global Custom Command, I have to open 7 Windows! QDK has to be changed so that it doesn't require so many windows, or it needs to be changed to an MDI interface (like ADRIFT)
3. The standard object type needs to be split into 3 types: The Standard Object, A Living Thing (ie humans, dogs), and modes of transport.
4. Different room types: Hallways, Halls (Large Rooms), Standard Rooms (Loungeroom), Stairwells (Large ones (in buildings), and Small Ones (In Backyards), Back and Front Yards, Caves, Forests, Parks, and Misc. Outside areas.
5. A built-in spell checker. Very few people are wiz-bang spellers, and this would help a lot.
6. Take out the entry for the room you are currently editing in the Compass tab. This really annoys me, because if I'm not careful, I can end up trapping the player in the one room, and game creators shouldn't have to be careful with a thing like that.
7. An easy way to review all compass points in the game in QDK, and Quest for debugging purposes (password protected)
8. A map feature (a definite must). This helps with the orientation.
9. Not exactly a high-priority one, but I'm including it just the same: A list of built-in story-lines, and to go with each story-line, is a complete set of starting off rooms and objects, as well as things like status variables like health for fighting games, and time for time-based games (like this one). To put it simply, in-depth templates.
10. I thought I'd put this out of curiosity. If the look at, examine and speak to text boxes are only one-line text-boxes, why do they have the height of three lines? This can confuse some programmers (including me) by tricking them into pressing enter when they want a new line. This will then close the dialog box.
11. A built-in ASL editor with Syntax Highlighting. This is another definite must, because it will help users learn ASL quicker.
12. This is one thing I would hate to see happen: A major change in the GUI. People get used to it, and a major change will generate anger (looking for a better synonym) among the Quest community.
13. A skinnable interface for the main gameplay screen in Quest. If skins are too hard, then color schemes. People soon get sick of the boring grey or black in a program. Look at WMP.
14. Maybe I'm being a little picky here, but I thought I should include it anyway: On the standard object Take Tab, the buttone that says "Edit..." next to the script box about for when the object is lost by the player is out of line with the other 2 "Edit..." buttons.
15. A password-protected debug mode in Quest.
16. Invisible status variables. Some people will argue: "That’s what normal variables are for." Sometimes, it makes it easier to use status variables, and we don't necessarily want it to show up, even if the value is greater then 0. For example, some authors might want to implement a score system, or an experience system, into their game. They might decide to use a status variable, it being easier to use ( plus the fact that it has a built-in script for when the value changes), and they won't want it to show up.
17. Escape codes for percent signs, hash signs, and any other special character that Quest sees as a variable/function.
18. A lot of the functions in TypeLib are pointless. If you set the object to an actor, then you cannot have a script run when you talk to someone. If you set an object as a regular object, then the take script and the when gained by player scripts don't run (and possibly the lost by player script too, I haven't tried). If you don't set it as a regular object, then it won't let you take it, and therefore the take script and gained by player script don't run anyway. This has forced me to use custom commands just to be able to take these objects.
19. There is a problem with the room descriptions. When you use anything other then standard, it will not display the usual "You are in:, there is such and such here, you can go there and there." What if the author wants to make a dynamic room description with all that stuff (like I did).
20. Not essential, but just an idea: room and object dimensions. This kinda goes with my earlier suggestion, room types. You wouldn't be able to fit a giant subwoofer in a hallway. Nor would you have one in a park, for example.

I will be happy to elaborate more on any of these points. Feel free to discuss, and please keep the myth of me being codingmasters out of it.

A lot of the functions in TypeLib are pointless. If you set the object to an actor, then you cannot have a script run when you talk to someone.

Plain and simply wrong on this point. You can have any script you want run when you talk to someone when using typelib (and it isn't even hard to do.)

If you set an object as a regular object, then the take script and the when gained by player scripts don't run (and possibly the lost by player script too, I haven't tried).

OK so the "take" script on the regular QDK interface doesn't work if you use typelib - a well known issue and one I have now fixed for the next version (at the time the current typelib was written it wasn't possible to neatly avoid this issue - it is now). If you don't want the default actions you can easily write your own take action instead which WILL work so I don't understand why this is a 'big problem' - admittedly it isn't as convenient as it might be, but hardly a deal breaker.

Agreed, lost/gained scripts only work with the default Quest take/drop/give constructs. This is mildly annoying but any custom command that moves objects is going to suffer from this problem - until we are given a way to trigger the inbuilt code that deals with these events we have to resort to extra coding to write our own gain/loss handling.

If you don't set it as a regular object, then it won't let you take it, and therefore the take script and gained by player script don't run anyway. This has forced me to use custom commands just to be able to take these objects.

As I said - nothing I can do about triggering the 'gained by player' script at the moment, but the whole point of typelib is that you use the object types provided, if you want a regular takeable object then that's the type to use.

I did have a version of typelib in which you could have some takeable objects that were NOT of any of the provided types - but it was not too successful because people would try to do things with the standard object that was only possible with the provided object types and thus generate error messages which indicated that action wasn't understood at all. By the time I'd error-handled all the commands that wouldn't work for a non typelib object the standard object wasn't 'standard' anymore...

Now for your other points...

Conversation system - my latest typelib (not released yet, but mostly working now) has this facility, NPC's can even 'learn' by being told things or reading things. I personally think this functionality is better added by a library (where we can easily get at it to change things we don't like!) than hard coded into Quest which means we might have to resort to nasty workarounds to get what we want if the 'as provided' code doesn't do exactly what we want.

3 standard objects? typelib provides a couple of dozen of these already! It is dead simple to 'tweak' a non human NPC type from the typelib provided "Actor"

Modes of transport? Not hard to do either, In the past (Quest 2.1x era I think) I've posted working examples of how to model space shuttles, transporters, magic carpets, motorcycles, magic carpets and elevators - sometimes you need an 'object' to do this, but more often you dont.

Modes of transport break down into two basic categories, things you ride IN (which means - think of a room in Quest) and things you ride ON ( think room and representative dummy object).

Objects wise I do think furniture (in the sense of bed / chair etc) and the implied ability to sit / lie would be a useful addition.

Cant see why you'd want different room types at all. 'Room' is just Quest's handle for "location" and you can use rooms singly or in multiples to model and sort of location you need. I did a piece set on a Sailing Ship a while back. As for room dimensions = use some properties with your rooms (height/width etc) - i.e. this functionality is already available.

Spell checker and syntax highlighting editor? Try Textpad, it works beautifully for Quest and is already a mature and classy product you can use for almost all your coding jobs (so why re-invent the wheel?)

Invisible Status variables... ahem - leave the display line blank and they are invisible!

Room descriptions - The manual shows how to replace room descriptions with ones of your own making that can mimic the original 'You are In' etc etc. It is cumbersome to do this admittedly, but it IS quite possible.

Map... don't agree at all, I hate the idea of automatic mapping, it isn't realistic. If you want your player to have a map put one in the game as an object and let him find/buy/be given it.

"Skins" for Quest? Personally I'm completely indifferent to this one, I would sooner Alex expended effort on improved functionality than on making the interface customisable.

Al (MaDbRiT)

Before I go on, let me say that this list is about 4 weeks old, and yes, some issues have already been sorted.

MaDbRiT wrote:

A lot of the functions in TypeLib are pointless. If you set the object to an actor, then you cannot have a script run when you talk to someone.

Plain and simply wrong on this point. You can have any script you want run when you talk to someone when using typelib (and it isn't even hard to do.)

When I said this, I meant that TypeLib only supports single line read actions. What if you want a script to run when you read something?

MaDbRiT wrote: If you set an object as a regular object, then the take script and the when gained by player scripts don't run (and possibly the lost by player script too, I haven't tried).

OK so the "take" script on the regular QDK interface doesn't work if you use typelib - a well known issue and one I have now fixed for the next version (at the time the current typelib was written it wasn't possible to neatly avoid this issue - it is now). If you don't want the default actions you can easily write your own take action instead which WILL work so I don't understand why this is a 'big problem' - admittedly it isn't as convenient as it might be, but hardly a deal breaker.[/quote]

Agreed, lost/gained scripts only work with the default Quest take/drop/give constructs. This is mildly annoying but any custom command that moves objects is going to suffer from this problem - until we are given a way to trigger the inbuilt code that deals with these events we have to resort to extra coding to write our own gain/loss handling.

This is one of the issues that has already been sorted out.

MaDbRiT wrote:

If you don't set it as a regular object, then it won't let you take it, and therefore the take script and gained by player script don't run anyway. This has forced me to use custom commands just to be able to take these objects.

As I said - nothing I can do about triggering the 'gained by player' script at the moment, but the whole point of typelib is that you use the object types provided, if you want a regular takeable object then that's the type to use.

I did have a version of typelib in which you could have some takeable objects that were NOT of any of the provided types - but it was not too successful because people would try to do things with the standard object that was only possible with the provided object types and thus generate error messages which indicated that action wasn't understood at all. By the time I'd error-handled all the commands that wouldn't work for a non typelib object the standard object wasn't 'standard' anymore...

This is another issue that has already been sorted out.

MaDbRiT wrote:Conversation system - my latest typelib (not released yet, but mostly working now) has this facility, NPC's can even 'learn' by being told things or reading things. I personally think this functionality is better added by a library (where we can easily get at it to change things we don't like!) than hard coded into Quest which means we might have to resort to nasty workarounds to get what we want if the 'as provided' code doesn't do exactly what we want.

This is something that I would be glad to see and use.

MaDbRiT wrote:3 standard objects? typelib provides a couple of dozen of these already! It is dead simple to 'tweak' a non human NPC type from the typelib provided "Actor"

Yes, but the point is that these things really should be built-in to Quest. It would therefore give MaDbRiT more time to work on other things in his libraries.

MaDbRiT wrote:Modes of transport? Not hard to do either, In the past (Quest 2.1x era I think) I've posted working examples of how to model space shuttles, transporters, magic carpets, motorcycles, magic carpets and elevators - sometimes you need an 'object' to do this, but more often you dont.

Modes of transport break down into two basic categories, things you ride IN (which means - think of a room in Quest) and things you ride ON ( think room and representative dummy object).

Yes, well I wasn't around these forums when Quest 2x was around. I wasn't supposed to know this. I'm not exactly sure why I put that in to be truthful, now that I think about it.

MaDbRiT wrote:Objects wise I do think furniture (in the sense of bed / chair etc) and the implied ability to sit / lie would be a useful addition.

Finally, some support for built-in commands!

MaDbRiT wrote:Cant see why you'd want different room types at all. 'Room' is just Quest's handle for "location" and you can use rooms singly or in multiples to model and sort of location you need. I did a piece set on a Sailing Ship a while back. As for room dimensions = use some properties with your rooms (height/width etc) - i.e. this functionality is already available.

I said this because Quest could handle the room description better for certain things. It would also help in the placement of objects; as I said, you wouldn't have a big stereo in a park

MaDbRiT wrote:Spell checker and syntax highlighting editor? Try Textpad, it works beautifully for Quest and is already a mature and classy product you can use for almost all your coding jobs (so why re-invent the wheel?)

The Spell Checker should be a built-in spell checker that scans the ASL file for all user-entered text and checks it for spelling errors.
The syntax highlighting should be part of a built-in ASL editor in QDK. This would make it easier for QDK users to learn ASL.
They should both be built-in to QDK.

MaDbRiT wrote:Invisible Status variables... ahem - leave the display line blank and they are invisible!

Thanks, I didn't realise that.

MaDbRiT wrote:Room descriptions - The manual shows how to replace room descriptions with ones of your own making that can mimic the original 'You are In' etc etc. It is cumbersome to do this admittedly, but it IS quite possible.

It may be possible, but these days users are looking for the easiest way of doing things.

MaDbRiT wrote:Map... don't agree at all, I hate the idea of automatic mapping, it isn't realistic. If you want your player to have a map put one in the game as an object and let him find/buy/be given it.

By a map I meant the same thing as ADRIFT's map. You've probably used ADRIFT, and would therefore know.

MaDbRiT wrote:"Skins" for Quest? Personally I'm completely indifferent to this one, I would sooner Alex expended effort on improved functionality than on making the interface customisable.

Probably, but if you take a look at MPlayer, I have put/am putting a lot of effort into making the interface customizable. Look at WMP. Microsoft have acutally employd The Skins Factory to make skins for WMP.

Hope that sheds some more light on my list.

Here's a couple ideas I had for ways to spruce up the QDK interface so i made a quick program in VB.

First image shows tabbed interface with treelist type interface for examining the tags, commands, properties, etc of objects and rooms.



Second image, example of room treelist, and exit editing, I think it'd be nice to have the option of directional exits running scripts if we so choose.


Third image, shows what I thought would be atleast a step towards the right direction in the manner of how QDK handles creating scripts, I liked the idea of updating script content, as this would basically serve to teach people qdk. Blah Blah, image.


Fourth one kinda, barely, shows the idea of having a right click menu on the treelist to offer clone, editing, or deleting of rooms, tags, exits, commands, or properties, and also the option to create a new instance of each type of script itself. Also room tag editing.



Of course I don't know how hard it all would be to throw together, I imagine not easy, but just my input. I'll post later with my opinions on all 007's ideas because, well, there is a lot to explain to you.

Also, Alex, how would you feel if someone came along with their own ASL creation type tool, would this step on your toes or no? As long as it wasn't being charged for I mean. Might be a good project for all these aspiring coders. Could start themselves a sourceforge or something.

Edit: Thumbnailed the images, should only be about 10k for all 4 thumbnails. Sorry folks, long day yesterday.

When I said this, I meant that TypeLib only supports single line read actions. What if you want a script to run when you read something?

The QDK interface for typelib offers an edit box where you can enter an 'action if read' - you put whatever script you want in here. In my original demo of this feature this option was used to transport the player to a magical land if he read a particular spell from a stone tablet.

(re animal types etc) Yes, but the point is that these things really should be built-in to Quest. It would therefore give MaDbRiT more time to work on other things in his libraries.

Don't agree here, I think that all commands should as far as possible be provided by way of external libraries (this is how TADS works b.t.w) and I do have a reason.

If functionality for (say) an animal object is hard coded into quest, what happens if we require it to function a little bit differently than the norm as provided? If it is 'hard coded' in Quest we have to work with what's provided and find ways to workaround/misuse and generally 'fight against' the existing code. If the functionality is provided as part of a library, we can simply remove the existing code completely and write what we want, thus not having to 'fight' the inbuilt functionality.

This means we get more flexibility if we add commands / functions externally than internally. Ideally the library that adds these functions should be transparent to the end user and appear easy to use as though indeed it is part of Quest, but remain accessible to more advanced users who want to change things.

(re beds, chairs, sitting and standing) Finally, some support for built-in commands!

Noooooo! Not built in commands! Seriously, I think these functions should be added by way of a library too, for exactly the same reasons as given above.

The Spell Checker should be a built-in spell checker that scans the ASL file for all user-entered text and checks it for spelling errors.
The syntax highlighting should be part of a built-in ASL editor in QDK. This would make it easier for QDK users to learn ASL.
They should both be built-in to QDK

.

I don't feel the need for this myself, but if you do I am sure you are not alone! What about (as an interim measure) a seperate user text extractor (as used by the ALAN system) so that you can run your text past a powerful grammar/spelling checker as is provided with MS Word/ Word Pro before releasing your game? That would be pretty simple to do.

By a map I meant the same thing as ADRIFT's map. You've probably used ADRIFT, and would therefore know.

Yes I know, and yes I have. I don't like this facility. It is not reliable in ADRIFT ('too complex' mapping errors abound in the games I've tried) and anyway I find it restrictive. It only works properly if your game world conforms to a very disciplined 'grid' of locations and mine never seem to.

That said it does seem to be a popular request so perhaps it could be implemented but disabled at the author's option.

Al (MaDbRiT)

ITID - I think your alternative QDK Interface looks like a very promising concept for those familiar with MS coding IDE's - more a half way house between a manual coding IDE and a super simple 'pointy-clicky' approach - be interested to hear Alex's response to this

I actually find ITID's proposed interface to be far better than the current interface. It looks a lot more straightforward and, better still, it's more eyecatching and likely to attract more people because of it.


As for the Adrift map issues: you get a too complex error message when the writer messes up with their room directions. If you go east then west and you don't end up at the first location again, you'll get an error warning. But I think Quest would benefit considerably from a feature like this. If you don't like it, don't use it. Adrift has a setting to turn off the map for game writers who prefer to have their players stumbling around in the dark.

As for the Adrift map issues: you get a too complex error message when the writer messes up with their room directions. If you go east then west and you don't end up at the first location again, you'll get an error warning.

Yep you do indeed, that is what I meant be enforcing a 'grid' system on the author. When I tried ADRIFT I had a location that was described as "a road initially heading north but curving away to the east" - which made the directional exits & locations "not make sense" in terms of a grid (I had to have North & East pointing to the same location) The mapping gizmo didn't like this much. There were other locations / exits it didn't like either, basically it was a P.I.T.A.

But I think Quest would benefit considerably from a feature like this. If you don't like it, don't use it. Adrift has a setting to turn off the map for game writers who prefer to have their players stumbling around in the dark

As I said, I'm not a fan of the idea, so if it is implemented in Quest it hope it is disable-able...

Al (MaDbRiT)

Oh yeah - I.T.I.D. much as I like your IDE ideas - could you please slightly reduce the size of your screen capture images when posting on the forum? Full screen width captures force the forum to need 1280 x 960 (or greater) screen real estate to avoid horizontal scroll bars in the text or the whole thread and that's as annoying as hell!

007bond wrote:13. A skinnable interface for the main gameplay screen in Quest. If skins are too hard, then color schemes. People soon get sick of the boring grey or black in a program. Look at WMP.

Media Player Classic fo' lyfe yo

OK, I've got a heap to go through, so here goes.

MaDbRiT wrote:The QDK interface for typelib offers an edit box where you can enter an 'action if read' - you put whatever script you want in here. In my original demo of this feature this option was used to transport the player to a magical land if he read a particular spell from a stone tablet.

This is another one, that after checking, I found that I was wrong. I think I meant the actor speak script though.

MaDbRiT wrote:Don't agree here, I think that all commands should as far as possible be provided by way of external libraries (this is how TADS works b.t.w) and I do have a reason.

If functionality for (say) an animal object is hard coded into quest, what happens if we require it to function a little bit differently than the norm as provided? If it is 'hard coded' in Quest we have to work with what's provided and find ways to workaround/misuse and generally 'fight against' the existing code. If the functionality is provided as part of a library, we can simply remove the existing code completely and write what we want, thus not having to 'fight' the inbuilt functionality.

This means we get more flexibility if we add commands / functions externally than internally. Ideally the library that adds these functions should be transparent to the end user and appear easy to use as though indeed it is part of Quest, but remain accessible to more advanced users who want to change things.

I see your point. I guess we'll just have to agree to disagree.

MaDbRiT wrote:Noooooo! Laughing Not built in commands! Seriously, I think these functions should be added by way of a library too, for exactly the same reasons as given above.

It certainly sounded like you were giving some support for built-in commands. Look here:

MaDbRiT wrote:Objects wise I do think furniture (in the sense of bed / chair etc) and the implied ability to sit / lie would be a useful addition.

I would call that support, if you interpret it like I did.

MaDbRiT wrote:I don't feel the need for this myself, but if you do I am sure you are not alone! What about (as an interim measure) a seperate user text extractor (as used by the ALAN system) so that you can run your text past a powerful grammar/spelling checker as is provided with MS Word/ Word Pro before releasing your game? That would be pretty simple to do.

That would be great if there was one. I still think that a basic spell checker should be implemented into QDK.

MaDbRiT wrote:Yes I know, and yes I have. I don't like this facility. It is not reliable in ADRIFT ('too complex' mapping errors abound in the games I've tried) and anyway I find it restrictive. It only works properly if your game world conforms to a very disciplined 'grid' of locations and mine never seem to. Laughing

That said it does seem to be a popular request so perhaps it could be implemented but disabled at the author's option.

Yes, I agree, I would like to be able to disable this if I wanted to. For those of you who have played Zelda Ocarina of Time, the first temple, just before you get to the boss: you can move the walls around. A situation like that would certainly mess it up. Don't forget that a player could make a map on paper though.

Just a last point: What was I meant to be looking at in your last post ITID? Was I meant to download something?

Here's the only suggestion off the top of my head for what I'd like to see in the next version of Quest & Questnet Server, along with some big claims.

#1 - Questnet Server Enter/Exit Room & Connect/Disconnect messaging customizations. These are elements of Quest that should be customizable through code. It serves to increase server script variances, and allows customization of game atmosphere and feel. Removing the hard coded nature of Quest to act like a game with rooms can encourage people to develop other kinds of servers using Questnet. Chat servers, chat networks, news servers, P2P, IRC, all through Quest? Why not?

You obviously didn't read my post about asking questions correctly...
Go read it. Go read the linked page. Then go sit in a corner and think about what you have posted... Then think about it some more until you realise what you've done!

I read 3 lines into it and was annoyed - I'm sure Alex would be more so!

I shall comment on thi as I go, so if anyone's already replied with what I post - I'll just emphasis that even more then.

1. Built in commands... You can do this by adding an action to the object or using a global command. The only exception maybe "#action# all", which maybe should be a universal thing to apply #action# to all the objects in the room (unless "in inv" is applied to the end).
Still - easily done yourself - and has different meanings depending on the game.

2. (your 1) Conversation system? Like what - you ask questions to someone and they give answers? Just do it yourself as everyone will want then to speak differently.

3. (your 2) Less windows is right. That will take an "overhaul" of QDK though - so I wouldn't expect it too soon... Something like he's done with the command screen (putting it into a node-tree window thing) would be ideal IMO.

4. Go and read that line again. Then realise why it's sensible to treat all objects the same.

5. Read this one again too. What's different between a hall and a normal room? - Just the description... Conclusion:: Slap yourself!

6. Spell checking is complex... Just load it into word and spell check it quickly.

7. Don't know what you mean here.

8. What?

9. Build / draw your own... You should when you design a game.

10. Right - you mean templates so you type of twats can come in, click one button and go "OOOO - I've created a game ALL BY MYSELF!"... F*ing looser (self-*'d).

11. (your 10) You type |n and that should do fine. RTFM

12. Textpad. Alex has already noted how QDK does NOT store ASL in memory - only saves it as ASL.

13. What? Conclusion2:: Slap yourself... AGAIN!

14. Why? You concentrate your time reading the text - not flapping around the screen going "this looks grey" (although you can change it by changing ALL of the windows stuff).

15. I don't know... Haven't opened up QDK in ages...

16. Or you could just switch it to "no debug" or something... Again, RTFM.

17. Just don't type anything into the "display" bit. Again - RTFM.

18. Escape codes? What the hell are you talking about?

19. That's mainly one reason I don't use it - although my other main reason is that using anothers' library (unlike C++ libraries) means this adds/alters the object which you're trying to customise - altering it to a "general" form, and to try and get it close to what you want... It's not as specific as you can do by yourself so I just go without... No offense intended at all because I'm sure it would be a great help to others out there - and a great time saver. - Just one I prefer not to use.

20. I haven't messed with it as it seems pretty adequate to me. I guess YOU'RE doing something wrong - so please RTFM.

21. I'm sure you could i it was a giant's hallway - or if you wanted to play to the entire park... If you don't want an object somewhere - DON'T PUT IT THERE YOU PRAT!!

22. ITID - that Editor example looks a bit complex - seems like it'd run into a couple of errors too... I don't like the extra "<tags>" type things on the rooms and what-not. BUT I do see bits of it which look nice.

23. A map feature - would be nice... To sort out that west->east issue then you'd just need to add a different colour line to another box. The real difficulty is getting these "boxes" in the right position!

24. Hah - I might just have to look into that classic WMP!
Got any screen shots to show us?

25. Library stuff is the way to go.

26. Stop trying to interpret.

27. You build one (Spell checker) and I'm sure Alex will use one...... Maybe.

28. You could always send a "refresh" down to the map screen - it wouldn't exactly mess it up.

Quest also needs a better way to specify colors for text. Currently there are the foreground and background scripts, and also the older |cl,|cr,|cg,|cy. I prefer the |c's to be honest as they can be thrown in like simple text formatting, and honestly it's easier to store them along with some text as a property for housing things like phrases to highlight and such.

I know Quest supports using the HTML color selecting scheme in a fashion similar to #FFFF00 scheme and these can be used with the foreground and background tags, but Alex, wouldn't it be possible to perhaps use them in text formatting as well? Perhaps something like |cc00FFFF for colorcodeTHISCOLOR or something easily memorable? Seems like a good thing to implement, and simple enough to do. If all these colors can work in the windows already, an easier way to call them in script seems logical.

This is my third disection of someone's post in the one thread.

Computer Whizz wrote:You obviously didn't read my post about asking questions correctly...
Go read it. Go read the linked page. Then go sit in a corner and think about what you have posted... Then think about it some more until you realise what you've done!

I asked you what exactly I was meant to read, and you never responded!

Computer Whizz wrote:I read 3 lines into it and was annoyed - I'm sure Alex would be more so!

I don't see how you can be annoyed.

Computer Whizz wrote:1. Built in commands... You can do this by adding an action to the object or using a global command. The only exception maybe "#action# all", which maybe should be a universal thing to apply #action# to all the objects in the room (unless "in inv" is applied to the end).
Still - easily done yourself - and has different meanings depending on the game.

The point I'm trying to make is that it would be a whole lot easier if they were built in. It means that it would take less time for game developers to write games, and more games would be released!

Computer Whizz wrote:2. (your 1) Conversation system? Like what - you ask questions to someone and they give answers? Just do it yourself as everyone will want then to speak differently.

Don't worry about this one. If you had bothered to read the previous post, you would have seen that Al already has one in the new version of Typelib

Computer Whizz wrote:3. (your 2) Less windows is right. That will take an "overhaul" of QDK though - so I wouldn't expect it too soon... Something like he's done with the command screen (putting it into a node-tree window thing) would be ideal IMO.

I know. This would be one to put on Alex's long-term goals for Quest

Computer Whizz wrote:4. Go and read that line again. Then realise why it's sensible to treat all objects the same.

Once again, it makes it easier for the developer.

Computer Whizz wrote:5. Read this one again too. What's different between a hall and a normal room? - Just the description... Conclusion:: Slap yourself!

It makes it easier for the game developer in the orientation of making all the rooms. For example, a park will have many walkways and many exits, not just eight. So, a park would have an option to take a certain path off to another place. If Alex ever implements a map feature, it could make the room look bigger to, like a hallway.

Computer Whizz wrote:6. Spell checking is complex... Just load it into word and spell check it quickly.

Yeah, but it's still going to go through all the tags, and other scripts. Somebody needs to write something that will extract the user-inputted text out of an ASL file.

Computer Whizz wrote:7. Don't know what you mean here.

If you used QDK, you'd know. On the compass tab in the room editing window, when you are selecting a compass point. The romm you are editing appears there along with the rest. Can't you just go through and look for the room name with some Do Until ComboBox.Text = currentRoomName, or whatever, and remove it?

Computer Whizz wrote:8. What?

By this I meant that there should be a giant visual map in QDK that lets us look at all the rooms, and create exits and drag and drop rooms into place, etc.

Computer Whizz wrote:9. Build / draw your own... You should when you design a game.

Once again, it makes it easier for the developer.

Computer Whizz wrote:10. Right - you mean templates so you type of twats can come in, click one button and go "OOOO - I've created a game ALL BY MYSELF!"... F*ing looser (self-*'d).

No, that is certainly not what I meant. People would know if he did that, obviously. What I meant is say you were wanting to make an adventure game. You could select this from the list of templates, but customize it, so that you could you could start from your house, or maybe a special meeting place, and you could set it to have health, but certainly not full games, just enough to get you started.

Computer Whizz wrote:11. (your 10) You type |n and that should do fine. RTFM

You appear to of missed the point. What I meant is that in the look at, examine and speak edit boxes, the textboxes are about three lines down. They should only be one, because they are not multi-line textboxes. I know how to get a new line though. It just confuses people.

Computer Whizz wrote:12. Textpad. Alex has already noted how QDK does NOT store ASL in memory - only saves it as ASL.

That maybe. He might need to start storing the ASL in memory.

Computer Whizz wrote:13. What? Conclusion2:: Slap yourself... AGAIN!

You didn't exactly have to comment on that one.

Computer Whizz wrote:14. Why? You concentrate your time reading the text - not flapping around the screen going "this looks grey" (although you can change it by changing ALL of the windows stuff).

Because people like to be able to customize everything. If you had an XBox that was chipped with EvoX, you would be suprised the amount of skins you can find for it.

Computer Whizz wrote:15. I don't know... Haven't opened up QDK in ages...

No real comment here, just thought I'd include it so that people don't get lost

Computer Whizz wrote:16. Or you could just switch it to "no debug" or something... Again, RTFM.

Didn't know there was an option to do so.

Computer Whizz wrote:17. Just don't type anything into the "display" bit. Again - RTFM.

Once again, if you had read earlier posts, you'd know that I had sorted out.

Computer Whizz wrote:18. Escape codes? What the hell are you talking about?

Ever heard of this little thing called HTML? There are about 200 escape codes in that. I reckon ASL needs them too, so that we can put in percentage signs and dollar signs without Quest thinking that it's a variable or function.

Computer Whizz wrote:19. That's mainly one reason I don't use it - although my other main reason is that using anothers' library (unlike C++ libraries) means this adds/alters the object which you're trying to customise - altering it to a "general" form, and to try and get it close to what you want... It's not as specific as you can do by yourself so I just go without... No offense intended at all because I'm sure it would be a great help to others out there - and a great time saver. - Just one I prefer not to use.

I use it for the clothes and containers mostly.

Computer Whizz wrote:20. I haven't messed with it as it seems pretty adequate to me. I guess YOU'RE doing something wrong - so please RTFM.

I don't believe so

Computer Whizz wrote:21. I'm sure you could i it was a giant's hallway - or if you wanted to play to the entire park... If you don't want an object somewhere - DON'T PUT IT THERE YOU PRAT!!

It just adds realism to the game.

The rest of the points were not to do with my list.

Just a couple of notes:
When is Alex gonna get on here and read it?
what on earth is RFTM
Hopefully the only other person's post I will have to dissect is Alex's.
Next time you dissect someone's post, make sure to quote it. It sure makes it easier for both the writer and reader.

You can easily scroll up - or press the "home" key... I I quoted everything my post would have been enormous! As this one is shorter I shall.

I asked you what exactly I was meant to read, and you never responded!

I told you what to read - the page. Print it out and read it on the bus/break/anything. Hell, have it printed many times and use it as wallpaper... Maybe that'll put some sense into you.

I don't see how you can be annoyed.

I'm annoyed at how insolent you are.

The point I'm trying to make is that it would be a whole lot easier if they were built in.

More games would be released? As I said, there's no common play command... You want to play ping-pong or play a video? Play a guitar?
Just add the script to the object actions (ie "play").
You don't ned to do anyting else as "play #object#" will activate this.

If you had bothered to read the previous post, you would have seen that Al already has one in the new version of Typelib

Unlike you - I actually DO bother to read - but I read the topic as I was posting... I also didn't need to read this post as he has had his new library in the works for some time and this subject has been covered. Still, my comment is valid, different methods to do it, and different results also wanted.

it makes it easier for the developer.

To be able to add a "person" or "car" as two different TYPES of objects? Use the "type". The current way makes it "easier for the developer".

It makes it easier for the game developer in the orientation of making all the rooms.

No - One type of room makes it easier for the developer. Giving it size in units - use the properties... I'm sure a map builder can get these size dimensions from that (sizeX, sizeY will prob do best).
You can currently have:many exits, many walkways etc.

Yeah, but it's still going to go through all the tags, and other scripts.

Add them to your dictionary then - all it is is a couple of |c and things like that. Just a simple read through of your text after puting some in will show up any spelling errors - it's what they call "proof reading!

The romm you are editing appears there along with the rest. Can't you just go through and look for the room name with some Do Until ComboBox.Text = currentRoomName, or whatever, and remove it?

I may want to go west to the current room - say you get into a room and want to do one of those "you're on a road that looks exactly the same as you just walked down, with a man riding a bike passing you... Wasn't that the SAME man just a second ago?" and have it KEEP going down that road until you say a misticle spell - or go back to town" or something... That's why it's there - because you CAN go back to the current room! You prat.

By this I meant that there should be a giant visual map in QDK that lets us look at all the rooms

You design one then.

Once again, it makes it easier for the developer.

The fact is it's quite complicated with LOADS of variations. Much easier to create a gif image by hand.

No, that is certainly not what I meant.
...
You could select this from the list of templates, but customize it

That's EXACTLY what you meant. You want a game created FOR you - with a variety of customisations.
A system (ie health&mp&what-not) is different, but can be added as a library IMO - I do want to do it, and will probaby begin it AGAIN friday... Might post up the code I had. Might actually continue it. Might do some rough beginner walkthrough things first. Need to sort myself out a "TO-DO" list and put it into an order...

They should only be one, because they are not multi-line textboxes. I know how to get a new line though.

Perhaps it's just that Alex forgot the "wordwrap" bit... I'm sure it's acidental.

He might need to start storing the ASL in memory

The way QDK was done in the beginning was to get it into modules I suppose. Letting people get at different "area's" of the game fast, so it needed to store it dynamically (ie - not in an ordered fashion like ASL).
If you order the editor into a node-tree style, you get rid of this as it's in memory fairly orderly, and any change to the raw ASL can be 'updated' when they leave the editor text-box.

Because people like to be able to customize everything

Kind of true. But when you're playing a text game you're still not looking at the window and saying "hmmm, that needs a bit of blue!". You're reading, imagining and typing... I've no objection to skins - but it isn't exactly a priority.

Didn't know there was an option to do so.

Then RTFM... That is the FIRST thing you do when you don't know the answer. Second thing is search the forums (hint::click the "search" button on the forums!). Third thing is to go read that link in the other thread because it describes EXACTLY these two points AND MORE!!!

Once again, if you had read earlier posts, you'd know that I had sorted out.

But it is again a symbol of your insolence to even TRY to do omething yourself. You want EVERYTHING handed to you on a golden platter. Go RTFM.

so that we can put in percentage signs and dollar signs without Quest thinking that it's a variable

Are you sure they're called "escape codes"? Either way, I know what you mean now and have one thing to say:: RTFM!!:evil:

It just adds realism to the game.

What - that there's no big speakers? Well I may want some big speakers in a 3inch high halway, simply because I am in a tardis hallway... Or a gun being sold in a candy store. Why? Because it's MY game and I can have it like that if I want it...

Don't start putting RESTRICTIONS into the game language you num-nut!

Alex might have already read tis tread - but had no oportunity/reason to reply. Just because one chooses to stay silent, doesn't mean one doesn't have ears.
RTFM (not rftm) is an acronym... Go look it up if you can be bothered to put any effort into anything.

Next time you dissect someone's post, make sure to quote it. It sure makes it easier for both the writer and reader

Don't you DARE speak to me like YOU have some advice for ME! Think before you speak little man.

.....

ITID - I quite agree... I was just looking at it and thought about the whole |cb thing... What if the default is green-ish and they wanted to make SURE the colour was black?
Well |cb would just set it to green-ish - the default colour:

Help File wrote:The |cb formatting code traditionally stands for black, but the foreground colour may be changed (by the foreground tag in the game definition block, or by the foreground script command), and so this code now always corresponds to the current foreground colour.

This tells us that the foreground is default-ed...

What about |cc (with "NULL" passed) to represent the current colour - or |cd as default. Then b would always be black.

I back ITID's colour thought though! (with maybe |cc(00FFFF) instead so it's easier to distinguish colour from comand - like a normal function/whatever.)

Currently, Questnet Server saves cloned rooms created on the fly in a game, as objects. To try this, make a little script and add it to an ASL file with a room already defined in it. Edit the script to have it clone your room, then save the server, shut it down, start it back up, and load the save. When you check the properties dialog, you'll notice the cloned room is now an object.

command <create new> {
       clone <MY ROOM HERE>
      }

Alex I would seriously appreciate if you could fix this in the next build of Questnet. I'm very close to having a stable server code to run and would like to put up something permanent for the Quest community. This bug here is part of the problem, as I can't be too positive things are backed up correctly if changes like this occur.

Computer Whizz wrote:You can easily scroll up - or press the "home" key... I I quoted everything my post would have been enormous! As this one is shorter I shall.

It just makes it easier on other posters if you go quote, and then split them up.

Computer Whizz wrote:I told you what to read - the page. Print it out and read it on the bus/break/anything. Hell, have it printed many times and use it as wallpaper... Maybe that'll put some sense into you.

That page is huge. I'm not gonna waste my time reading somthing that I don't need to.

Computer Whizz wrote:I'm annoyed at how insolent you are.

RTFL

Computer Whizz wrote:More games would be released? As I said, there's no common play command... You want to play ping-pong or play a video? Play a guitar?
Just add the script to the object actions (ie "play").
You don't ned to do anyting else as "play #object#" will activate this.

I'm not talking about play, i'm talking about commands like open, close, lock, unlock, climb, etc.

Computer Whizz wrote:Unlike you - I actually DO bother to read - but I read the topic as I was posting... I also didn't need to read this post as he has had his new library in the works for some time and this subject has been covered. Still, my comment is valid, different methods to do it, and different results also wanted.

If you know how to read you would not of said what you said in your previous post

Computer Whizz wrote:To be able to add a "person" or "car" as two different TYPES of objects? Use the "type". The current way makes it "easier for the developer".

You're missing my point. When you add a character, it has special options like speak, give, and other things. An object won't have speak or give, but it might have put in/on.

Computer Whizz wrote:No - One type of room makes it easier for the developer. Giving it size in units - use the properties... I'm sure a map builder can get these size dimensions from that (sizeX, sizeY will prob do best).
You can currently have:many exits, many walkways etc.

Yeah, but if you want just compass points, you only get eight, and sometimes this isn't enough.

Computer Whizz wrote:Add them to your dictionary then - all it is is a couple of |c and things like that. Just a simple read through of your text after puting some in will show up any spelling errors - it's what they call "proof reading!

Yeah, but if QDK had this built-in, it would save time.

Computer Whizz wrote:I may want to go west to the current room - say you get into a room and want to do one of those "you're on a road that looks exactly the same as you just walked down, with a man riding a bike passing you... Wasn't that the SAME man just a second ago?" and have it KEEP going down that road until you say a misticle spell - or go back to town" or something... That's why it's there - because you CAN go back to the current room! You prat.

Then you can have a special function that puts a script there, dumbass.

Computer Whizz wrote:You design one then.

How do I get it into QDK?

Computer Whizz wrote:The fact is it's quite complicated with LOADS of variations. Much easier to create a gif image by hand.

Yes, but what if you only want the player to see only where they have been. That is what makes the ADRIFT map function unique.

Computer Whizz wrote:That's EXACTLY what you meant. You want a game created FOR you - with a variety of customisations.
A system (ie health&mp&what-not) is different, but can be added as a library IMO - I do want to do it, and will probaby begin it AGAIN friday... Might post up the code I had. Might actually continue it. Might do some rough beginner walkthrough things first. Need to sort myself out a "TO-DO" list and put it into an order...

Yeah, but it will only have starting things, like health and a starting room, and maybe a character to help you. Not a full game.

Computer Whizz wrote:Perhaps it's just that Alex forgot the "wordwrap" bit... I'm sure it's acidental.

That's why I put it in there. Just to let him know.

Computer Whizz wrote:The way QDK was done in the beginning was to get it into modules I suppose. Letting people get at different "area's" of the game fast, so it needed to store it dynamically (ie - not in an ordered fashion like ASL).
If you order the editor into a node-tree style, you get rid of this as it's in memory fairly orderly, and any change to the raw ASL can be 'updated' when they leave the editor text-box.

That's another option that could be looked into by Alex, if he ever gets back on here!

Computer Whizz wrote:Kind of true. But when you're playing a text game you're still not looking at the window and saying "hmmm, that needs a bit of blue!". You're reading, imagining and typing... I've no objection to skins - but it isn't exactly a priority.

I think so to, but because you don't know how large the person's screen resolution is going to be, or if they have two monitors plugged in, you should have an option that lets you put the panes on the left.

Computer Whizz wrote:Then RTFM... That is the FIRST thing you do when you don't know the answer. Second thing is search the forums (hint::click the "search" button on the forums!). Third thing is to go read that link in the other thread because it describes EXACTLY these two points AND MORE!!!

You have an attitude problem. Try and be nice for once.

Computer Whizz wrote:But it is again a symbol of your insolence to even TRY to do omething yourself. You want EVERYTHING handed to you on a golden platter. Go RTFM.

No I don't. I like a challenge in life.

Computer Whizz wrote:Are you sure they're called "escape codes"? Either way, I know what you mean now and have one thing to say:: RTFM!!:evil:

Well that's what they are called in HTML.

Computer Whizz wrote:What - that there's no big speakers? Well I may want some big speakers in a 3inch high halway, simply because I am in a tardis hallway... Or a gun being sold in a candy store. Why? Because it's MY game and I can have it like that if I want it...

Don't start putting RESTRICTIONS into the game language you num-nut!

Right now I am feeling the urge to call you something really mean.

Computer Whizz wrote:Alex might have already read tis tread - but had no oportunity/reason to reply. Just because one chooses to stay silent, doesn't mean one doesn't have ears.
RTFM (not rftm) is an acronym... Go look it up if you can be bothered to put any effort into anything.

I know, but it is to do with his product, so you would assume that he would have something to say about it.
I know that RTFM is an acronym. I ain't stupid.

Computer Whizz wrote:Don't you DARE speak to me like YOU have some advice for ME! Think before you speak little man.

You need anger management CW. Seriously.

Once again, the rest of the post has nothing to do with me, so I won't be saying anything.

Another "Quest Need"...

I've already mentioned that we need to be able to control the messaging scripts for when players connect or disconnect, but we should also be able to control the messaging scripts for when players enter or exit rooms using traditional commands or when moved via script (goto or move).

If you can't fit this into the next version Alex, could you alteast perhaps change things so that when a player is both concealed or hidden messaging of that player entering or exiting rooms is not displayed? HIDE on player objects will stop the connect messaging from being displayed to other users in the start room when connecting, but does not stop the enter/exit messaging from being displayed to other users.

Really seems like there should be a way to hide users movements and connections, either simple(by hiding them) or complex(by letting us specify the scripts).

That page is huge. I'm not gonna waste my time reading somthing that I don't need to.

... My response to that is a bank stare. Obviously you are beyond help of any kind.

RTFL

A-huh... And what label is that? I've read loads of labels - the label on you is "IDIOT".

i'm talking about commands like open, close, lock, unlock, climb, etc.

opening a book is different from opening a door or box - or a person (if you open them with a knife) - same with the others.

If you know how to read you would not of said what you said in your previous post.

I've already explained that it's a valid response and just in addition to what they said - infact I explained myself TWICE or more times IIRC - in my original post and in my follow up.... This in fact proves YOU cannot read well along with the fact of your lack of effort.

You're missing my point. When you add a character, it has special options like speak, give, and other things. An object won't have speak or give, but it might have put in/on.

I can speak into a microphone, or to a furby, or to anything inanimate - sometimes they can even respond (like a walkie-talkie).
You know this is REALLY easily solved with a "character" library addition that you can put together - oh, I'd better correct that - which *I* can put together in a couple of hours tops (yeah - I've been away from programming for a while and I'm not sure exactly how much I would need to put in it). Oh, and you can put stuff on people too.

Yeah, but if you want just compass points, you only get eight, and sometimes this isn't enough.

You want him to put all 360` into the compass points? 8's traditionally enough, although I'm sure the exit "ssw" or "wsw" is far beyond you.

it would save time

You checking it in word is quicker and easier for everyone involved... Typo's and spelling mistakes aren't uncommon... Beta testers can solve this.

Then you can have a special function that puts a script there, dumbass.

Why have extra code to go AROUND a problem YOU want there - when you can just NOT click on the current room? This makes extra trouble for the developer - something you're against... Right? So who's contradicting himself?

Yeah, but it will only have starting things, like health and a starting room, and maybe a character to help you.

Sounds like a start room and a health system to me.

You have an attitude problem. Try and be nice for once.

This is 'being nice'. I'm trying to make you THINK - which is something I shall discontinue with.

No I don't. I like a challenge in life.

A-huh. So you NOT doing the BASICS to get a RESULT is 'liking a challenge'... Well I guess I like sky-diving in that case as I've only seen it a couple of times on TV and films.

Well that's what they are called in HTML.

Fair enough... I know only enough HTML to do what I want. I'm sure I could get into it more but web pages are of ittle interest to me.

Right now I am feeling the urge to call you something really mean.

Fair enough - if you have a GOOD reason to. I am not one to sink into mindless name-calling, and will only make fun of your responses to do so. My valid point was met by you wanting to call me a name.

I know that RTFM is an acronym. I ain't stupid.

I'd disagree. If you can acknowledge it's an acronym I'm sure you can google it in 5 seconds (like I did with your RTFL)... Or you could think about it for 3 seconds and come up with the result (maybe thinking of different words beginning with "m", to do with the PC, and can help you with dong something is a good start and a BIG hint).

You need anger management CW. Seriously.

I respond with valid points, and all I get in return is either a clarification in terms, a contradiction, or an avoidance of "ouch - you're mean!"... In response to this lack of a proper reply, I shall no longer put any effort towards you.

I'm not even gonna bother dissecting that

007bond wrote:I'm not even gonna bother dissecting that

Aw, we were really hoping you would...

Cares a lot wrote:

"007bond"

I'm not even gonna bother dissecting that

Aw, we were really hoping you would...

/nod

Looks like Mr. Bond has been 'out smarted'

That's the coolest animation I've ever seen. Hahaha

steve the gaming guy

Mr. Bond has not been outsmarted. And it would certainly help if Firefox did not block the damn images. I'll check them when I'm at school tomorrow.

Believe it or not, there's actually an option in Firefox not to block images.

davidw wrote:Believe it or not, there's actually an option in Firefox not to block images.

OMG!! REALLY!?!?

... heh, actually I thought it was more of an option TO block images...

That was 007Bond's benefit actually. Despite being a Codingmaster-type fellow, he's clearly not much of a master at coding.

I didn't realise that it had enabled an option. Yep, I can now see every image on every website. Cool animation ITID, and that's a nice new sig CW