Although I don't think Quest support's variable name's! Eg. Whatever you want the name to be can vary since the player can name it WHATEVER he want's!

I'd like to see ALOT of things coming into Quest, and almost ALL of them would involve variable's in some way/shape or form .

Oh, and about that do <variable> thing..... I have been informed (and have come across something like it) that you CAN call a procedure using a variable as a pointer in :
C/C++ (my dad as source.... book's soon to come!)
Visual Basic (it's called CASE..... it's not EXACTLY a call variable - but close!)
and firST BASIC (you could use a function where it called a procedure using a function ---- I'll try and scan the book if you want, if my father hasn't taken it that is!)
I'm not sure about any others..... BUT WE WANT MORE VARIABLES!!!!

quote:

---

Oh, and about that do <variable> thing..... I have been informed (and have come across something like it) that you CAN call a procedure using a variable as a pointer in :
C/C++

---

Yes you can do something like that, (roughly speaking a 'pointer' is used to index a memory location where the variable value 'lives' regardless of what it is called) - and in my opinion it is one of the best ways of making really BAD C++ programs that are really hard to follow and very bug prone.

Pointers generally are one of the reasons I hate having to work with C++ at all - they are just too easy to get into a mess with. (Most people find learning how to use pointers is the hardest bit of C++ for good reason.)

One of C++'s biggest problems is that it provides the coder plenty of rope with which to hang himself and innumerable convenient scaffolds. :-)

Just because you CAN do something doesn't make it automatically a good idea. :-)

I don't personally think Quest needs anything as potentially confusing as pointers, it is supposed to be a relatively easy to learn and use adventure writing system after all. With what we already have and a bit of lateral thought most things are possible without having to resort to hard to comprehend advanced coding methods.

Just my opinion - but why not just use INFORM if you want to get into C/C++ style complexity of coding?

I replied assuming you meant something like an old fashioned BASIC might do with a calculated GOSUB call e.g.

quote:

---

100 GOSUB 100 + (X% * 100)
200 moveplayer T0 kitchen
210 RETURN
300 moveplayer TO lounge
310 RETURN
etc.

---

Thats bad, because it isn't immediately obvious where the flow of the program will go, and of course an unexpected value of X% will almost certainly trash the program. This is the main problem with allowing the contents of a variable to control program flow in a very direct way.

However a SELECT CASE as in modern BASICS option would be lovely, it would allow the contents of a variable to control flow in a less direct, more limited way. It would also remove the need to write masses of IF THEN ELSE conditions. Something like :-

quote:

---

SELECT CASE X%
CASE 1 goto <kitchen> END CASE
CASE 2 goto <lounge> END CASE
CASE 3 goto <hallway> END CASE
CASE >= 4 goto <garden> END CASE
CASE DEFAULT msg <You spin aimlessly...> END CASE
END SELECT

---

Now that WOULD be useful don't you think? This construct is easier to follow and allows for unexpected values of X% to be dealt with without crashing the program.

How easy it would be to add it to Quest is another matter entirely ;-)

Al

[/quote]

C.W. is right, you can get the effect you want by manipulating the ALIAS tags, here's an example:

quote:

---

define game <Naming Rooms>

asl-version <300>

game version <1.0>
game author <MaDbRiT>
game copyright <� 2001>
game info <No info>
start <startroom>
command <name house #moniker#> {
property <#quest.currentroom#;alias = $capfirst(#moniker#)$>
exec <look>
}

end define

define room <startroom>
look <A nondescript modern house.>
alias <a nameless house>
north <room2>
end define

define room <room2>
look <A nondescript modern house.>
alias <a nameless house>
south <startroom>
end define

define text <intro>
Simply type 'name house |iname|xi to change the name of each house!
end define

define text <win>
Enter win text here
end define

define text <lose>
Enter lose text here
end define

---

You can cut, paste and run that to see it in action.

Al

And even if you DID allow for a user inputted variable, then you'd make a little routine to make sure that it was within the specified range.... but tat would still be a bad idea!

Oh, and leaving note's (Rem's, // or /*'s) are always a good idea to remember what the HELL you were thinking of after you drank those 15 beer's .

I didn't actually know you could set it like that!! WOW.... I'll have to remember that.
Oh, and I'd rather stick to Quest for the time being ;) BASIC has, and always will be, the programming language in my heart!

quote:

---

Hmm... "select case". One for the to do list... I'm sure you're responsible for 90% of all Quest features, Al!

---

While it's true I have made lots of suggestions that have led to Quest features, 90% is probably a bit of an exaggeration!

Most of my suggestions have been based on limitations or difficulties I've hit actually using Quest to create things, so they (hopefully) represent the kind of true 'user feedback' that the beta releases were intended to generate.

The fact is that suggestions put forward are always given proper consideration and implemented if they make sense within the context of what Quest is about, so I for one am quite happy to continue making them.

quote:

---

It would actually be really easy for me to make Quest allow "do <#mything#>". At the moment it deliberately doesn't interpolate #mything#. But I think it's my duty to force you to try to code properly

---

I agree entirely, allowing that would be a recipe for chaos. If I may take the liberty of quoting myself from the post a few messages above?

quote:

---

Just because you CAN do something doesn't make it automatically a good idea. :-)

---