This is similar to a topic i bought up 8 years ago..... doesn't time fly

David Whyld wrote:Probably not a very helpful response, but I'd scrap the item carrying restrictions. They're a pain and if you include one in your game, people will only complain.

Searching for a related topic i came across the above and agree it isn't very helpful, but 8 years on and many headaches later; i must admit it is practical. Can't say i am perturbed about people complaining: water off a ducks back.... get on with it, or get out; play it, or don't play it; I do what i do because i enjoy it and have a lot of frustrated fun? I do not have to simplify matters !!....

However; I still have the restriction as i want the 'game play' to be sensible in that you can't pick up an item if both your hands are full. I have used tasks and changes within the ALR to achieve this and can get the item, put it in a bag (which has it's own restriction), and of course the reverse. This is ok and works well.

The present problem arises when i try to do two things at once, or pre-empt what the user may type, and irrespective of my restrictions, the system carries out the command.e.g.My hands are full. The bag is full. I can see an item. I go to get the item with the reply "you can't your hands are full". .....great, and so are all the other responses relevant to getting and putting.

If i use sentences, i.e. get the item and put the item in the bag; or try to pre-empt the user by typing put the item in the bag,....... very very complicated.

Input get item and put item in bag has a reply of:I can't get the item because my hands are full.(Taking the item first)I am now carrying an item. I can't put the item in the bag as it is full.

Input put item in bag has a reply of:(Taking the item first)I am now carrying an item. I can't put the item in the bag as it is full.

As can be seen it makes the game very messy, unnatural, and not very sensible.

So bearing in mind that i want to retain my privilege of having restrictions; how can i STOP the system overrides?

continuation....... This applies to a few peculiarities. Assuming you have been to a room on a previous game and remember seeing an item there,(in this game it has not yet been created), if you input put item in bag the reply will be: I have put that inside the bag.

Hey Highways, could you make a small one room demo showing your approach and upload/attach it to a post here in the forum? While I have some ideas how I might do it, I've never actually played around with it before and was wondering what your approach looked like.

The command:get the item and put the item in the bagwill run the get the item task, and then run the put the item in the bag task, as if you had typed two separate commands.

put the item in the bag normally responds:You are not carrying the itemYou must have overridden or altered this task to automatically pick up the item if you are not holding it and try to put it in your bag.This task seems to be missing the restriction that your hands are not full.

If you need more help I will need to see either your TAF file or the output from the debugger when it executes this command (set to high detail level)

Hi ElliotM. The taf file is attached. There are some differences in this file compared to big brother, which probably has 20+ get/put tasks. There is always the probability that in some instances they are interfering with each other?? However, if we can get this small file working properly then i have the basis to work from.

"Take table" is prevented by your restriction, as the response is bold."Take all" says there is nothing worth taking here, but isn't bold, so I know its a default response. There is obviously stuff worth taking here, so I find that response misleading. Will have to think about how to handle that one."Take all on table" is prevented by your restriction, as the response is bold.

"Take all from table" is currently allowed, however, and results in some really strange stuff that breaks your system, even though it doesn't actually move anything to your inventory. Try it first in a fresh game and you'll get the output: "I take the glass and the bag from the table. I am now carrying a table. I am now carrying a table. I am now carrying a table." If I do an inventory check, I have nothing. Repeat the command "Take all from table" and you'll get: " I am now carrying a table. I am now carrying a table. I am now carrying a table. I can't get a table because my hands are full I can't get a table because my hands are full." If I try to take anything else, I can't because "I can't get a table because my hands are full", even if the object I tried to get wasn't the table.

I suspect that Adrift 4 is outputting the result of every restriction that fails. I think Adrift 5 stops after just one.

saabie wrote: your hands variable is only being incremented when the bag is picked up.

Have tried different scenarios with/without bag... same problemI have gone back to 'basics' and re-tried the system restriction - i picked up all 5 objects???

using same taf file, i have removed all tasks other than [get*%object%] with a single restriction [hands must be less than or equal to 3 - or message hands full] action is [move object to held by player + same expression to increase hand]

Scene 1get 4 objects ok. get 5th object. (hands full)

Scene 2changed carrying restriction [hands must be less than 4]as above. even tried rotating the pick up of objects!!

Scene 3changed action other way round; [expression is first]as above

Scene 4created a new task. [get*%object%] restriction [hands must equal 3], no action, completed message is [hands full], placed it first, and it worked.

I can't for the life of me see why putting a restriction in a different place should effect what the system does?

However, having got over that hurdle i will start re-inputting other restrictions and putting in bag etc and see what happens.

ElliotM wrote:"Take all from table" results in some really strange stuff... I am now carrying a table.I suspect that Adrift 4 is outputting the result of every restriction that fails. I think Adrift 5 stops after just one.

I have noticed that if i input 'get object from bag' and a restriction is in place to stop it happening, then i have had a quirky 'i am now carrying a bag'?

Talking of restrictions i have messaged saabbie regarding how 2 tasks are required just to restrict the player from carrying more than allowed.

[quote="ElliotM"]"Take all" says there is nothing worth taking here, but isn't bold, so I know its a default response. There is obviously stuff worth taking here, so I find that response misleading.

Hi ElliotM, just a thought on the above; i would change the ARL to read something like "Don't try and confuse me! what exactly do you want me to take?".ARL,s are a good way of getting round some obstacles; the obstacle is still there, it just doesn't look so bad!!

Many, Many, hours later..... I think i am starting to bow down to what a lot of greater minds than mine have indicated; that there is no solution to this problem.

I have attached a taf file which shows that the operation will action correctly providing the player uses straight forward 'one time' inputs.

saabie wrote:The #get object (object in bag) and (object not in bag) tasks are both specific to "a bag", so your hands variable is only being incremented when the bag is picked up.

Not sure i understand this. Wouldn't the same ruling apply to the 'table'. ?

I have attached a taf file regarding the issue of restriction in get and put as far as 'putting object in bag'. I can't see the point in developing the 'get from bag' until this situation is rectified.

I'm looking at this with the ADRIFT 5 developer so I don't know what it looks like using the ADRIFT 4 geneator.In the first demo taf.taf the two #get object tasks are shown as being set to only run if the object being taken is the bag.So when you pick up the bag the variable is incremented, but when you pick up anything else then your task does not run and the variable is not incremented.

In get&put tasks.taf if i pick up the glass and then type "put glass in bag", it is not matching your put*%object%*bag command and is running the default put object in object instead.It doesn't work because the first * has no input to match with, and there are no spaces to separate the words.put %object% in bag would work better.

I also see command lists like this:#drop object - not alloweddrop*%object%put*%object%downput down*%object%ADRIFT 5 says that it is an error to have one line start with # and other lines with references.

P.S. I do think that it would be easier to do this in ADRIFT 5, as it lets you change most of the default responses and can be made to do anything you want, without the limitations of ADRIFT 4.