i've never properly understood the purposes behind these 2 differences. I've read the document, and tested it. What I got, is when I added the '@' symbol, a menu appeared asking me which one I was referring too (I had 2 different objects with the same alias in the same room).

I made a small test game with it, using the '@' symbol, and then not using the '@' symbol. Sometimes it put the object in my inventory, sometimes it didn't, without '@' altogether, it just puts the object in my inventory without asking which one.

Here is my code for the room:

define room <room>
	command <pickup #food#> {
		if ( #food# = beans ) then give <#food#>
		msg <You picked up some #food#>
	}

	define object <fooditem001>
		alias <beans>
		take
	end define

	define object <fooditem002>
		alias <beans>
		take
	end define

end define

The @ symbol uses the build-in Quest engine to go from an alias to the real object name - or vice versa.
This means, any game with the same alias will be automatically disambiguated - because there are two in the list.

I'd guess the one by just using "#object#" would just go for the first one it would find, although the "will it/won't it" seems like it doesn't like finding more than one.

If yous dun wanna box appearing, then go through it by yourself.
Just grab a list of objects that use that name (although, you'd have to make your own "alt" tag), then disambiguate between them.

Say I have 3 objects in a room that I can use another object on (3 monsters, and I have a sword). When I drag the sword object over to the monster object, I don't want it to ask me which one I'd like to use it on, I'd like it to use it on the monster I dragged the sword onto.

Same thing when pressing "Take", if I have an object selected, Quest must already use #@object# when it runs the Take command on an object.

I don't want this menu to appear, I want it to interact with the object it has selected, if it has not selected an object, it just interacts with the first object with that alias, in the list.

Don't give the three monsters identical names.

Freak wrote:Don't give the three monsters identical names.

What if you want 3 Skeletons to attack you in the Dark Caves?

I mean, you can make one a "tall skeleton", and another an "ancient skeleton".

I guess i'd just be forced to have Skeleton001, Skeleton002, Skeleton003, all with the Alias of Skeleton, and just accept that the annoying "CHOOSE AN OBJECT YOU'VE ALREADY SELECTED" window comes up lol.

Give them different aliases.

Yeah, but then it's more work for the user as they have to type more, meanwhile these three skeletons are kicking their butt!

It would make the dragging work properly.

Or you could use "skel1" "skel2" "skel3" as alt tag variants.

If you were making Quest, how would you implement that part of the program?
Would you code it so that it takes the real object name and uses that in the background somehow - or would you simply have it put that command through your parser using the object alias?

Which one is:
more correct, simpler, easier?

The second.. That is, simulate the player typing in a command.
Doing a use simply puts the alias of the object into a "use" command, and then it passes it to the Quest parser.. Otherwise you don't know WHAT you'd end up with - not to mention duplicating code etc.

Personally - I see no shame in putting "skeleton(2)" when there's more than 1 of the same skeleton - it helps clarify, especially when typing.

Thanks for this topic.

I have the same issue in my game. In a room, I have three objects with the same name, but want each one to be named the same, but be interacted with separately. Having aliases such as Name1, Name2, Name3 can look rather subpar. Like in GB's skeleton example. 3 listings of "skeleton" would appear more realistic than... I'm slaying skeleton1 or slaying skeleton2. And the programmer shouldn't have to be forced to define each skeleton's characteristics differently, especially if all skeletons are the same. I chose the menu-option since at least to a player the menu can appear to add variety to the game's interaction style.

-Witch