You could have the certain lift name, and stick the floor's as the array number! Then it referrs to the array and takes you to the right room!

Al.... How did you do the lift before?

quote:

---

Al.... How did you do the lift before?

---

Well my elevator (which I confess I wrote and used as a transporter in a Star Trek type edu-game for eight year olds) was designed for Quest 2.15 etc - we didn't have arrays or runtime changeable exits back then so it was a completely different problem!

However - this is a brief outline of how it worked. My docs supplied with it explain how to use it, but not really how it crunches.

Essentially the elevator was a standard quest room, with one exit only (OUT of course!). The author provided as many wayds as he needed to enter the elevator with a standard direction tag e.g. north <>, this has to call a procedure like this:

east do <E_L_Enter_Elevator_Proc>

The names of the rooms that the elevator could travel between had to be supplied to the library as a list separated by asterisks in a string variable, like so:

setstring <elevator.lib.floornames;first_floor*second_floor*__
third_floor>

Also needed a variable or two set up, see the docs for that, but the primary one was :-
setvar <elevator.lib.floors;3>

This was needed to set the number of potential floors. Both these were to be set in a startscript along with the ability to customise the library's messages etc.

When the player enters the elevator roon, the procedure evaluates which of the floors he entered from and the lifts behaviour is modified accordingly - it doesn't move if you select the floor you are already on for instance.

Using the lift buttons (simple Quest user commmands) modify the a 'current floor' variable, so that when the player leaves the elevator, ( a Quest command overriding OUT in the elevator room) he is put on the floor that corresponds to the variable.. an example.

Player goes 'north' from 'floor_2' - the enter elevator procedure is called and evaluates this as the second item in the list so current floor is set to 2 and the player is moved into the elevator room.

He presses button 2 - the lift doors re-open and he is told he selected the floor he is already on... see why I needed to evaluate it?

If he presses button 3, the lib checks that this is a different floor to the current one, and prints a 'moving' message and updates 'current floor' to the button pressed (3), now when he uses OUT it puts him in the room that corresponds to 3 in the floornames list = Third_Floor... and there you have it!

Now it would be easier to do - we can vary exits and have arrays, but you still need the main body of the code as is to get a good result.

As a matter of interest, I have a new for Quest 3.0 version of my old "standard lib" idea - this one does the container trickery just like the old one did, but adds some other useful features, there are several useful types built in etc, etc.. I hope to have this ready for the release version of Quest 3.0.

I know Wizard is producing a melee library and a maze library for Q3, I have also got a working but incomplete layered clothing library, an elevator library and a vehicle library all in the pipeline - along with Q3 tutorials for hand coding and thru QDK..

My libs and Wizard's will become available soon from my Quest Tips and Tricks page.

But I reckon it can be done in a very little amount of code!
A little to check the current floor and the button pressed. A little to check that the number isn't out of bounds (it wouldn't be nice if the player made a mistake and had quest shut down!). A little to select the right room from the array. That's it isn't it!?

..... but, as you said, Quest didn't have ALOT of these features back then. I myself started using quest when there was Quest 2.16/2.17. And a pre-release of Quest 3.0 alpha, or something like that...... It was recently after this new board opened up!!

Evaluate? How'd you do that?

quote:

---

Actually, the way you describe it, the code is ABSOLUTELY HUMUNGOUS! LOL
But I reckon it can be done in a very little amount of code!
A little to check the current floor and the button pressed. A little to check that the number isn't out of bounds (it wouldn't be nice if the player made a mistake and had quest shut down!). A little to select the right room from the array. That's it isn't it!?

---

As I say, the provision of arrays and variable exits makes the elevator a MUCH easier thing to do in Q3 than it was in Q2, the bulk of my 'absolutely humungous' code was taken up with manipulating the string variable to use it as an array of sorts, and altering the exit from the elevator room to point to different rooms.

It's a measure of how flexible Quest ASL is that even though those constructs didn't exist natively in 2.1x, one could code a way to simulate them - even if the code itself got a little complex here and there.

quote:

---

..... but, as you said, Quest didn't have ALOT of these features back then.

---

Exactly. Because doing an elevator WAS a bit convoluted in Q2.1x I made the code into a relatively easy to use library. I find that making code into a customisable add in library in this way also makes the code much bigger and more complex than coding into a game file direct.

The idea was that even using QDK and with a minimal knowledge of ASL code, one could easily add elevator functionality by just adding the lib and setting a few variables - all explained in the manual.

That approach doesn't make for the smallest and easiest to follow code, but it does make for easy to use, relatively robust libraries that should work unaltered for most author's purposes - which I personally feel is how libs ought to be.

I have a fully working Q3 elevator library on my PC at present, but I have not yet written any documentation, it will appear on my website soon though and you can see for yourself just how much less complex it is! :-)

Given that is is still user customisable though, there is a bit more to it than you might expect!