OK. Again, sorry if this has been asked before. I did try the forum search, but the results just confused me.

I want to use objects together, but without using the use command.

For example I currently have a Brass Lantern and a Box of Matches. I have managed to set the script so that light lamp checks to see if you have the lamp (whether it is lit) and if you have a box of matches.

If you have both items, and it is unlit you will light it. If you only have the lamp (and it is unlit) it will tell you to find something to light it with. If the lamp is lit, whether or not you have any matches, it will tell you it is already alight.

My question here is how do I specify the light lamp command to be light lamp with matches.


Similarly, in one locoation I have some form of shaft and a metal post stuck in the ground. I have created the shaft as an object so that the player can examine it, and see by looking at it, that it is too deep to just climb down.

Basically I want the player to have to tie rope to post before he can climb down the shaft. But I want to avoid just plainly using the rope on the shaft.

I am planning on having panes disabled, but ideally dragging the matches on the lamp or the rope on the post should not be able to work if my settings are over ruled by the player.

For the light lamp question.

Create a command called: light lamp with matches
in the light lamp script commands, IF player has matches
and Lamp is not already lit, then light lamp and remove matches(if is just one match).

Not sure if thats what you wanted to know by that question.

For the shaft question

Just like the 1st answer,

Use commands, this way the player cannot simply use one object on another.

not sure if this helped or not.

My question here is how do I specify the light lamp command to be light lamp with matches.

One method is to make the 'light lamp' command call a 'light lamp with matches' command if the player has matches to begin with:

command <light lamp> {
    
    if got <matches> then {
        exec <light lamp with matches>
    }
    else {
        if not property <lamp; lit> then {
            msg <You should find something to light it with.>
        }
        else {
            msg <The lamp is already lit.>
        }
    }
}

command <light lamp with matches> {

    if got <matches> then {
        if not property <lamp; lit> then {
            msg <You light the lamp.>
            property <lamp; lit>
        }
        else {
            msg <The lamp is already lit.>
        }
    }
}

There are two problems I see with doing it this way. One, referencing the lamp or the matches by any of their alternate names won't work - each command would have to be modified to account for each alternate name. If you change the alternate names for these objects later on, you'd have to remember to come back to these commands and change them here, too. For instance, if the lamp has been described as 'a small green lamp', then the command would need to account for all possible ways of referencing the lamp:

command <light lamp; light green lamp; light small green lamp; light small lamp>

The second problem is use of the 'exec' script command, which just forces another command to execute as though the player had typed it themselves. This means that the beforeturn and afterturn scripts (for the game as a whole and for the particular room the player is currently in) will fire twice. If you've got any upkeep code in these scripts, that might prove a nuisance. I'm particularly thinking of the game afterturn script, where it might be common to increment a 'turn' variable to keep track of how many turns have passed since the game started. If the player types 'light lamp' (and they have the matches), then 'light lamp with matches' will automatically execute. After it is finished the afterturn script will fire and control will be passed back to the 'light lamp' command, where the afterturn script will fire once more.

A better way is to implement a combination of verb and command, and then to put all the functionality for the lamp within the definition block for the lamp itself. Here is the verb I'm thinking of:

verb <light: OnLight> msg <You cannot 'light' that.>

This verb is exactly equivalent to the following command:

command <light #@object#> {

    if action <#object#; OnLight> then {
        doaction <#object#; OnLight>
    else {
        msg <You cannot 'light' that.>
    }
}

Since Quest's verbs can only specify one noun (one object), you cannot implement 'verb OBJECT with OBJECT' as a verb (such as 'light lamp with matches'). So here is a command that mimics the logic of a verb:

command <light #@object1# with #@object2#> {

    if action <#object1#; OnLight> then {
        property <#object1#; with = #object2#>
        doaction <#object1#; OnLight>
    }
    else {
        msg <You cannot 'light' that.>
    }
}

This second command behaves in exactly the same way as the verb, save that it sets a property (called 'with') on the object being lit to the object that is making the lighting possible. (It sets the 'with' property of the lamp to 'matches'.) In the verb and the command no script has been written that actually lights the lamp yet: that's to be done in the OnLight action of the lamp itself, which both the verb and the command call:

define object <lamp>

    take
    properties <with = NULL>

    action <OnLight> {

        set string <this; $thisobject$>

        if not property <#this#; lit> then {
            if (#(this):with# = NULL) then { 
                if got <matches> then {
                    property <#this#; with = matches>
                    doaction <#this#; OnLight>
                }
                else {
                    msg <You should find something to light it with.>
                }
            }
            else {
                if (#(this):with# = matches) then {
                    msg <You light the lamp.>
                    property <#this#; lit>
                }
                else {
                    set string <str; #(this):with#>
                    msg <You cannot light the lamp with #(str):prefix# #@str#.>
                }
            }
        }
        else {
            msg <The lamp is already lit.>
        }

        property <#this#; with = NULL>

    }

end define

The above action (OnLight) first checks to see if the lamp is already lit. If it's not, the script looks to see if an attempt was made to light this object (the lamp) with anything. We store any object that was used to try to light the lamp in a 'with' property on the lamp itself. By default this property is set to NULL, and as you can see at the end of the OnLight action, it is reset to NULL after any attempt to light the lamp has been made. If the 'with' property is NULL, a check is made to see if the player possesses the matches. If they do, we set the 'with' property to 'matches' and recall the OnLight action immediately. If they do not possess the matches, we tell the player they need to find something to light the lamp with.

If the 'with' property does not equal NULL, we check to see if it equals 'matches'. If it does, the lamp is lit. If it doesn't (as when the player tries to light the lamp with, say, a 'shoe'), a message is sent to the player indicating that they cannot light the lamp with whatever object they tried to light it with. (IE, "You cannot light the lamp with a shoe.")

As for the rope:

verb <tie: OnTie> msg <You cannot 'tie' that.>
command <tie #@object1# to #@object2#> {
    if action <#object1#; OnTie> then {
        property <#object1#; to = #@object2#>
        doaction <#object1#; OnTie>
    }
    else {
        msg <You cannot 'tie' that.>
    }
}

define object <Post> {

    properties <CanTieRopeOnMe>

end define

define object <Rope> {

    properties <to = NULL>

    action <OnTie> {
        'check to make sure 'to' doesn't equal NULL.  If it does,
            'inform they player that they must tie the rope to
            'something, they can't just 'tie rope'.
        'if 'to' doesn't equal NULL, check if the object it refers to
            'has the 'CanTieRopeOnMe' property.  If so, tie the
            'rope to that object, otherwise send a denial message to
            'the player.
    }

end define

There is (at least) one other thing you'd have to take care of in the OnTie action: the rope has two ends that can be tied, so you'll need to keep track of how many objects the rope is currently tied to. If it's already tied to two things then you shouldn't be able to tie it to any more objects. (Unless you can cut it, in which case I leave that coding nightmare up to you.)

The above method won't interface at all with 'use OBJECT on OBJECT', nor will dragging items in the panes trigger any of the above functionality. Attached is a sample you can check out.

Thank you both very much. You have given me a lot to think about.

I was going to go with Redsun until Overcat replied.

And to some extent I may still do... As defining 1 command might be all I need.

However, the method shown by Overcat, defining the "with", is the closest to what I want (so the player can try mixing items).

IK am going to sit down and chew it all over, but you have been very helpful.

Thank you.

Be careful about having a rope in your game. Ropes are notorious for being trouble objects. There's a lot you have to get right with them.

Is there something in the quest engine that causes that - or is it just peoples interpretation of how to "use" them?

How messy is this for my "rope" situation?

' Created with QDK Pro 4.1 Beta

!include <stdverbs.lib>

define game <>
	asl-version <410>
	start <test>
	game info <Created with QDK Pro 4.1 Beta>
	command <tie rope to post> {
		if got <rope> then {
			if here <post> then {
				msg <You tie the rope to the post.>
				lose <rope>
				flag on <ropedown>
				unlock <shaftentrance; down>
				hide <rope> } else msg <There is no post here.> } else {
			msg <You don't have any rope.> }
	}
end define

define options
	debug on
	panes on
	abbreviations on
end define

define room <shaftentrance>
	look <there is a shaft down>
	down locked <bottomofshaft; The shaft is too deep to jump down.  You will need to find another way down.>

	define object <rope>
		take
		displaytype <Object>
		article <it>
		gender <it>
		use on <post> 
	end define

	define object <post>
		look if flag <ropedown> then msg <A metal post with a rope tied to it.> else msg <A metal post.>
		displaytype <Object>
		article <it>
		gender <it>
	end define

end define

define room <bottomofshaft>
	look <You are at the bottom of the shaft.  A rope leads up.>
	up <shaftentrance>
end define

Freak wrote:http://www.inform-fiction.org/manual/html/s50.html#p402

Noted - thanks for the link

Overcat wrote:

[snip]

Since Quest's verbs can only specify one noun (one object), you cannot implement 'verb OBJECT with OBJECT' as a verb (such as 'light lamp with matches'). So here is a command that mimics the logic of a verb:

command <light #@object1# with #@object2#> {

    if action <#object1#; OnLight> then {
        property <#object1#; with = #object2#>
        doaction <#object1#; OnLight>
    }
    else {
        msg <You cannot 'light' that.>
    }
}

This second command behaves in exactly the same way as the verb, save that it sets a property (called 'with') on the object being lit to the object that is making the lighting possible. (It sets the 'with' property of the lamp to 'matches'.) In the verb and the command no script has been written that actually lights the lamp yet: that's to be done in the OnLight action of the lamp itself, which both the verb and the command call:

define object <lamp>

    take
    properties <with = NULL>

    action <OnLight> {

        set string <this; $thisobject$>

        if not property <#this#; lit> then {
            if (#(this):with# = NULL) then { 
                if got <matches> then {
                    property <#this#; with = matches>
                    doaction <#this#; OnLight>
                }
                else {
                    msg <You should find something to light it with.>
                }
            }
            else {
                if (#(this):with# = matches) then {
                    msg <You light the lamp.>
                    property <#this#; lit>
                }
                else {
                    set string <str; #(this):with#>
                    msg <You cannot light the lamp with #(str):prefix# #@str#.>
                }
            }
        }
        else {
            msg <The lamp is already lit.>
        }

        property <#this#; with = NULL>

    }

end define

The above action (OnLight) first checks to see if the lamp is already lit. If it's not, the script looks to see if an attempt was made to light this object (the lamp) with anything. We store any object that was used to try to light the lamp in a 'with' property on the lamp itself. By default this property is set to NULL, and as you can see at the end of the OnLight action, it is reset to NULL after any attempt to light the lamp has been made. If the 'with' property is NULL, a check is made to see if the player possesses the matches. If they do, we set the 'with' property to 'matches' and recall the OnLight action immediately. If they do not possess the matches, we tell the player they need to find something to light the lamp with.

If the 'with' property does not equal NULL, we check to see if it equals 'matches'. If it does, the lamp is lit. If it doesn't (as when the player tries to light the lamp with, say, a 'shoe'), a message is sent to the player indicating that they cannot light the lamp with whatever object they tried to light it with. (IE, "You cannot light the lamp with a shoe.")

[snip]

I am playing with this, and am liking it a lot (thanks). I do have one more question though.

Say for arguments sake I had several items throughout the game (lamps, candles, fires, &c.), is there a way I could call the contents of the OnLight script without having to write it out for each item?

If I am understanding the syntax correctly, running the command light @object1 with @object2 checks to see if @object1 has the OnLight script, and if it does it runs that script.

Is it possible to still do that, but have the OnLight script point elsewhere.

I was toying with procedures, but am not quite sure how to point everything all over the place.

I was trying to straight swap some of the OnLight code inrto the procedure, but I can't get it to work.

Quest can handle the generalizing of different "kinds of objects" quite nicely with "types".

A type, as pointed out recently here, is just a collection of properties and actions that any object can inherit. For instance:

define type <item>

    take
    weight = 10
    size = rather small

    action <OnAttack> {

        set string <this; $thisobject$>
        msg <Now why would you attack #(this):prefix# #@this#?>
    }

    action <OnInspect> {

        set string <this; $thisobject$>
        msg <The #@this# weighs #(this):weight# stones and is #(this):size#.>
    }

end define

This sets up a type called 'item'. You can read more about types in the documentation, here. The item type above can be "tacked on" to any object:

define object <apple>

    look <Just an apple>
    prefix <an>

    type <item>

end define

Even though you've only defined the apple object with two tags (look and prefix), it also inherits all the properties and actions from any types it has been declared as. In this case, the apple will inherit the take tag, a 'weight' and 'size' property, and an 'OnAttack' and 'OnInspect' action.

If you had verbs such as these:

verb <attack: OnAttack> msg <You can't 'attack' that.>
verb <inspect: OnInspect> msg <You can't 'inspect' that.>

...then typing 'attack apple' would message "Now why would you attack an apple?", and 'inspect apple' would message "The apple weighs 10 stones and is rather small."

It should be noted that whereas an object has its user-defined properties defined with the 'properties' tag, a type does not use the properties tag (I'm not sure why this is the case):

define object <someObject>

    properties <weight = 10; size = rather small>

end define

define type <someType>

    weight = 10
    size = rather small

end define

So rather than create a procedure or function to generalize the lamp behaviour (which you well can do), you can use a type, as shown below. Remove the OnLight action and 'with' property from the lamp object and insert them into a 'lightable' type. Then make the lamp object of the 'lightable' type. (You must alter the OnLight action somewhat, so as to handle all sorts of lightable objects, not just the lamp.)

define type <lightable>

    with = NULL

    action <OnLight> {

        set string <this; $thisobject$>

        if not property <#this#; lit> then {
            if (#(this):with# = NULL) then { 
                set string <lightingObject; $GetValidLightingObject$>
                if (#lightingObject# <> NULL) then {
                    property <#this#; with = #lightingObject#>					
                    msg <(with #(lightingObject):prefix# #@lightingObject#) |xn>
                    doaction <#this#; OnLight>
                }
                else {
                    msg <You should find something to light it with.>
                }
            }
            else {
                if type <#(this):with#; lighting> then {					
                    set numeric <i; $objectproperty(#(this):with#; uses)$>
                    if (%i% > 0) then {						
                        property <#this#; lit>
                        dec <i>
                        property <#(this):with#; uses = %i%>						
                        doaction <$thisobject$; AfterLight>
                        if (%i% = 0) then doaction <#(this):with#; WhenEmpty>
                    }
                    else {
                        doaction <#(this):with#; UseWhenEmpty>
                    }
                }
                else {
                    set string <str; #(this):with#>
                    msg <You cannot light the lamp with #(str):prefix# #@str#.>
                }
            }
        }
        else {
            msg <The #@this# is already lit.>
        }

        property <#this#; with = NULL>
    }

    action <AfterLight> {
    }

end define

Then you can define the lamp as follows:

define object <lamp>
	
    take
    prefix <an unlit>
    look <Just a lamp.>
		
    type <lightable>		
		
    action <AfterLight> {
		
        msg <The lamp sputters, almost dies out, then burns brightly.>
        property <$thisobject$; prefix = a lit>
    }
	
end define

Now you'll have already noticed that there is a lot more going on here than before: there is a function in the 'lightable' type called 'GetValidLightingObject'; we're tracking something called 'uses' on the object that lights the lamp; the lamp changes it's prefix from "an unlit" to "a lit"; and so on. I'm not going to explain everything, I'll let you play with it.

There is also a type called 'lighting', which defines a type of object that can be used to light another object (like the matches). In the attached file there are matches and a lighter, as well as four objects that can be "lit": a campfire, candle, torch, and lamp. The lighter has very little fuel in it, and can only be used once. The matches can be used three times. Just experiment with changing things up - if you have any questions, are not sure how a particular effect is occurring, or don't know what some of the ASL is for, ask away. Remember, the documentation is one click away.

Once again, thank you for taking the time to give such a good explanation.

I shall play away.

BTW - I downloaded Lighting&Lightables. It opens fine in QDK 4.0.5, but when I open it in 4.1 beta I get the following message...

Error 438 - Object doesn't support this property or method

in QDKGame.InitialiseTypes

My brain hurts.

Getting back into the code... I am trying to fine tune it so that the adventurer can ONLY light things if he possesses them.

I have tried editing the command to achieve this, and have taken:

command <light #@object1# with #@object2#> {
	if action <#object1#; OnLight> then {
		property <#object1#; with = #object2#>
		doaction <#object1#; OnLight>
		} else {
		msg <You cannot 'light' that.>
		}
}

And added a further conditional statement. It now looks like this:

command <light #@object1# with #@object2#> {
	if got <#@object1#> then {
		if action <#object1#; OnLight> then {
			property <#object1#; with = #object2#>
			doaction <#object1#; OnLight>
			} else {
			msg <You cannot 'light' that.>
			}
		} else {
		msg <You don't have that.>
		}
}

But doesn't seem to have made any difference.

When I try to Light X I get the maybe you need to find something spiel whether or not I have the lamp in my inventory.

I am also trying to set a flag LampOn so that I can control rooms that need illumination. But again here I am struggling.

I have it working in a simpler test file where I have added the verb Light and therefore all I need to do is Light Lamp (this was for testing only, as I wanted to use the Light X with Y formula.

The only problem I have with that is that while I have the conditional script set to check for the object in your inventory or in the room, unless you are holding the lit lamp, the room goes dark again
I have tried

define room <BottomOfShaft>
	alias <bottom of the shaft>
	prefix <the>
	look <The mine seems to have been abandoned for some time.>
	description {
		msg <You are at the bottom of the shaft.|n>
		if got <Lamp> and flag <LampOn> or here <Lamp> and flag <LampOn> then 
		msg <#quest.lookdesc#> else 
		msg <It is very dark!>
	}
end define

and

define room <BottomOfShaft>
	alias <bottom of the shaft>
	prefix <the>
	look <The mine seems to have been abandoned for some time.>
	description {
		msg <You are at the bottom of the shaft.|n>
		if got <Lamp> or here <Lamp> and flag <LampOn> then 
		msg <#quest.lookdesc#> else 
		msg <It is very dark!>
	}
end define

Carrot wrote:

...

I am also trying to set a flag LampOn so that I can control rooms that need illumination. But again here I am struggling.

I have it working in a simpler test file where I have added the verb Light and therefore all I need to do is Light Lamp (this was for testing only, as I wanted to use the Light X with Y formula.

The only problem I have with that is that while I have the conditional script set to check for the object in your inventory or in the room, unless you are holding the lit lamp, the room goes dark again
I have tried

define room <BottomOfShaft>
	alias <bottom of the shaft>
	prefix <the>
	look <The mine seems to have been abandoned for some time.>
	description {
		msg <You are at the bottom of the shaft.|n>
		if got <Lamp> and flag <LampOn> or here <Lamp> and flag <LampOn> then 
		msg <#quest.lookdesc#> 
		else msg <It is very dark!>
	}
end define

and

define room <BottomOfShaft>
	alias <bottom of the shaft>
	prefix <the>
	look <The mine seems to have been abandoned for some time.>
	description {
		msg <You are at the bottom of the shaft.|n>
		if got <Lamp> or here <Lamp> and flag <LampOn> then 
		msg <#quest.lookdesc#> else 
		msg <It is very dark!>
	}
end define

I appear to have solved that last one by re-arranging the conditional.

description {
		msg <You are at the bottom of the shaft.|n>
		if got <Lamp> and flag <LampOn> then 
		msg <#quest.lookdesc#> else 
		if here <Lamp> and flag <LampOn> then 
		msg <#quest.lookdesc#> else 
		msg <It is very dark!.>
	}
end define

And added a further conditional statement. It now looks like this:

command <light #@object1# with #@object2#> {
   if got <#@object1#> then {
      if action <#object1#; OnLight> then {
         property <#object1#; with = #object2#>
         doaction <#object1#; OnLight>
         } else {
         msg <You cannot 'light' that.>
         }
      } else {
      msg <You don't have that.>
      }
}

But doesn't seem to have made any difference.

Well, you were on the right track. You must omit the @ symbol when referencing the object inside the command script. If you had put "if got <#object#> then {" instead of "if got <#@object#> then {", it would have worked.

You would have had to update the lightable type as well, to also check if the player possessed the object they wished to light. I've improved the LightingAndLightables demo to do this, as well as changed it to implement the 'article' property of objects. You can read about this property here. The candle is now 'a bound set of candles', and has the article 'them', as opposed to 'it'.

Also, you cannot take the campfire, (which makes sense). The lightable type is smart enough to figure out that you don't need to possess the campfire in order to light it. Any lightable object that is takeable, however, (the rest of them) will require that the player possess that object before they can light it.

Thank you yet again.

Carrot wrote:BTW - I downloaded Lighting&Lightables. It opens fine in QDK 4.0.5, but when I open it in 4.1 beta I get the following message...

Error 438 - Object doesn't support this property or method

in QDKGame.InitialiseTypes

Would just like to report I am getting this error witht hte new version of L&L as well in 4.1, but still works fine in 4.0.5

Would just like to report I am getting this error witht hte new version of L&L as well in 4.1, but still works fine in 4.0.5

Which is odd, because I wrote that with 4.1 beta. Perhaps one of us is not using the latest version. Will reinstall to see if that's the case on my end.

---edit---

Nope - works for me after reinstalling latest 4.1 beta. Are you sure you've downloaded and installed the newest version?

Had a quick play with that, and I am currently trying to swap a few things round.

example, when you try to light lamp without holding either the lamp or matches/lighter you get the message

You should find something to light it with

But if you pick up some matches say, and then try to light lamp (that is still on the floor) you get the message

(with a set of matches) You must possess the lamp to light it.

which seems a bit strange that you can try to light a lamp if you don't have the lamp or the matches, but as soon as you have the matches you can't try to light the lamp.

I know all I have to do is give the error msg from command <light #@object1# with #@object2#> to overide that in define type <lightable>

But I am struggling to work out how to do that.

Overcat wrote:

Would just like to report I am getting this error witht hte new version of L&L as well in 4.1, but still works fine in 4.0.5

Which is odd, because I wrote that with 4.1 beta. Perhaps one of us is not using the latest version. Will reinstall to see if that's the case on my end.

---edit---

Nope - works for me after reinstalling latest 4.1 beta. Are you sure you've downloaded and installed the newest version?

Ahhh - I was using build 4.1.202

Have just U/G to 4.1.210

And now it opens fine.

My Bad

which seems a bit strange that you can try to light a lamp if you don't have the lamp or the matches, but as soon as you have the matches you can't try to light the lamp.

Yeah, that is somewhat inconsistent.

I know all I have to do is give the error msg from command <light #@object1# with #@object2#> to overide that in define type <lightable>

Yes, you would have to change that, and make another change in the lightable type. You basically just want to check for possession (if the 'lightable' object is possessable) before you make the check to see if the player has a valid 'lighting' object. I've made both changes. I've also altered the GetValidLightingObject function - it's smaller and more efficient.

Playing with this, and using it to modify some other things . You have been very helpful, thanks.

One thing though...

I downloaded that latest file, opened it up, ran it and it worked fine.

I added an extra room, created an exit to it from StartRoom, saved and run it again (All within QDK Pro 4.1).

And the decsription is now minus the red line listing the exits.

I have tried this several times and always get the same result.

Any ideas?

If you run that file and open the ASL Log Window, you'll see:

4:04:31 PM INIT: Quest Pro 4.1 (build 4.1.60)
4:04:31 PM INIT: Opening file C:\Users\Jonathan\Documents\Desktop\LLmodified.asl on 09/06/2009
4:04:31 PM ERROR: No script given for 'afterlight' action data
4:04:31 PM ERROR: No script given for 'afterlight' action data
4:04:31 PM ERROR: No script given for 'afterlight' action data
4:04:31 PM ERROR: No script given for 'afterlight' action data
4:04:31 PM ERROR: No script given for 'whenempty' action data
4:04:31 PM ERROR: No script given for 'whenempty' action data
4:04:31 PM INIT: Finished loading file.
4:04:32 PM ERROR: No string variable 'quest.doorways.out' defined.
4:04:32 PM ERROR: No string variable 'quest.doorways.dirs' defined.
4:04:32 PM ERROR: No string variable 'quest.doorways.places' defined.

I found two things:

1) Actions that I'd defined with no script in them had their curly braces removed by Quest. This is a bug, as the action needs them (or Quest generates the 'no script given for action data' error.)
2) The ASL version was changed from 400 as in the example to 410. This is a 410 bug, which doesn't seem to set normally built-in string variables, such as #quest.doorways.dirs#. I have a feeling this has to do with the way exits are being implemented now.

Item 1 can be remedied by adding the curly braces to the empty actions that need them. So, for instance

AfterLight

should be changed to

AfterLight {
}

Item 2 can be fixed by manually setting the asl version tag back to <400> instead of <410>.

Thanks, I'll sort that out.

Those quest.doorways.out/dirs/places variables are obsolete in Quest 4.1, replaced simply by #quest.doorways#.

How are things coming along Carrot?

To be brutally honest, I haven't done much lately.

Today, on top of being Fathers Day here in Blighty, is also my 6th Wedding Anniversary. I have also been working long hours AND I will be moving house soon (hope to get completion dates middle of next week). So been very busy

but I haven't forgotten about it.

One thing I am trying to work on is darkness. I am trying to work out the best way for a character to walk around tunnels, lets say, with a lamp - but not to be able to without. I was thinking of using flags. The one dilema I have come up with so far is what if the adventurer, for whatever reason, put the lamp down in a room.

I was thinking that I would either have to make the lamp un-droppable in certain locations. The other otpion would be to somehow control the exits.

I am currently working on a script that is along the lines of "if have, or if currentroom". The problem with that is leaving the room if not picked up. The problem with removing the currentroom side of things is the moment you put the lamp down it all goes dark (not very realistic).

My third issue is with revealing the exits once the room is lit. Say we are at the bottom of the shaft and there are exits N and U, we only want to show U until the lamp is lit becuase "It is very dark".

I will admit to have not put much time (see above) into to trying to solve these issues, but the one thing I did stumble across to start with is the room description script you very kindly helped me with shows the other exits.

I did have a thought that lighting the lamp could create exits, but once lit but left elsewhere those exits would still be visible.

I have a lot to think on here, and I haven't even got a real storyline yet either.

But I am trying

There are several different ways of doing all of those things.

I would recommend trying to come up with a "generic" way of implementing light/darkness. That way if you create, for instance, a glowing wand as an unanticipated development, you won't have to adjust your code to accommodate the wand's emission of light. So any dark location that has an exposed "lit" object in it would show a description, otherwise it would not.

If you need help coming up with a way to do this, let me know. (If so, start a new thread with a descriptive title.)

A few other things to keep in mind:

1) What happens if the player puts the lamp in a container?
2) What happens if the player tries examining things while it's dark?
3) If the room is dark, and the player tries referring to an object on the floor, what happens?

Yeah, good things to remember. Also, if the room is dark it may still be plausible to "feel" or "feel around for" ambient objects, though I haven't attempted to script that yet.