Oh dear Phil Seems Ive to much time on my hand here lol

Just a thought is there an opportunity to add to the object code where the objects are currently;
~ Container ~ Wearable ~ Static ~ Light source

Could there be an option for container code to be spilt into CONTAINER SURFACE . In this way you have an option of

Look in chest =
In the Chest x is.....object-object.

Look on tray =
On the tray is ......object - object
The difference is that the the command requires the Look ON for surface and Look IN for container

The sysmess response would then of course reply for the appropriate object type

On the "surface" is ........

and the present in the "container" is...........

The author then could possibley use the weight factor if they wish the suface to be static i.e like shelf

There are obvious expansion areas then to the "static" flag where the static object could be a continer or a surface but thats pushing the boundries a little at this stage I believe.

Whats your thoughts? Bearing in mind that your time is precious as well..


Gareth

Hi Gareth,

I know we've covered this before a couple of times...

This thread shows how to do it longhand using a spare unused location as the SURFACE of an object, which you can then put things on/take things off or "look on" and even describe what is ON an object as a message appended to a location description via Script One.

https://adventure.forumotion.com/t84-multiple-objects-on-a-static-object

I agree it would be nice to set an option in the Object Editor (like you have container, weight, light source attributes etc..) with default Response entries etc but the problem there would be compatibility with existing games or databases. They would not load into TAB because of the changed loading structure.... unless I can figure a way around that...
I'll have to have a think and come back to you on that.

Phil.

Hi Gareth,

Think I've figured a way to do it using the "Object Start Location" numerical field box on the Object Editor....
If I widen it a little to allow an extra number to be inserted and allow higher numbers to be accepted we could create a rule that an object could be deemed to be ON another object if its start room was set to be the surface object's number + 1000.

For instance if you had a table defined as object 6 then any objects set to start at 1006 would be classed as being on the table.

I created a "lookinobj" ACTION routine to auto deal with "looking on" objects...

[start]look on %objn2%#objlocn2=here[acts]lookonobj#else#objlocn2=absent[acts]cmessThere is no %objn2% here![end]

I created an unused system message (47): "On the "

So you get something like this:

You are in a room.

You can see:
a table.

>look on the table

On the table is:
a bloodstained knife.

Or if nothing on the table...

>look on table

On the table is nothing at all.

Now I will work towards making some default actions for:

get <obj> off <surface object>
drop <obj> on <surface object>

These will be just default entries and it will be the responsibility of the author to adjust/create code to handle object size and weight factors that may be necessary.

Bye for now,
Phil.

Aaaarrr. YES I remember that discussion now - I new somewhere in the dark, empty spaces of my mind that we'd discussed something of this matter and I'd forgotten that there would be issues with pre-existing games being loaded in.

However, that solution youve hinted upon may be a very useful tool and from a programming point of view perhaps cut done on a huge people not wanting to use sufaces as puzzles. As I siad earlier - no big rush at all if you can do it great if not no biggy at all. Its about enjoying.....

Thanks again

gareth

Hi Gareth,

I'll see what I can do - but doing the way I am suggesting would mean there is no way for TAB to know if an object actually is a surface object as there would be no attribute to indicate this to TAB at present. Also there could not be any conditions to check if a particular object was one or not....
So there's quite a lot more to this than I originally thought.
Phil.

Mmmmm seems like a nightmare of work to do it mate..

As this is the suggestion area I suggest leave it for now because its not fair on you to pile hours in when we have a work around in place. Its not like there is nothing out there.


Perhaps in time some more obscure things members need can be placed into a form of FAQ or how to catalogue so that we look it up on those odd occasions (as with my game at present) that we need it a little like the tutorial. I suppose its something that all members can contribute to in the marjority ( that way the monkey is not passed to you soley)

Would it be an easy point of putting a forum area for these things here so that its a form of member self help?

LOL told you Ive to much time on my hands now didnt I....

Gareth

Hi Gareth,

I think for purposes of the game that ANY object can be deemed to have a surface....

So the player could "look on <anyobject>"

To place an object ON to another object place it at the surface objects object number +1000

eg: if a table is object 6 then putting things to 1006 is effectively placing them on to the table surface...

So the default RESPONSE entry action "lookonobj" will list any objs present there...

On the table is:
a penknife.

For the next update I've made a couple of extra actions:

lookonbjn2 - same as lookonobj (uses objn2)
lookonbjn1 - same but for object noun1
listsurfaceX - does same thing as lookinobj but for object X.

I think you'll be able to use the "anyobjs" suite of conditions and "listobjsX"
action as well for these surface room locations > 1000 too:

#anyobjs1006#

#listobjs1006#

But I don't think there's much more I can do regarding these types of object locations because of the limitations I explained earlier..

If you have any further thoughts let me know, Gareth.

Phil.

Hi Gareth,

I also made two condition/action tags to help in designing coding entries to handle 'surface' objects for the next release...

%surfacen1%

and

%surfacen2%


So you can make entries like these for instance:

[start]get all off %objn2%#objlocn2=here#anyobjs%surfacen2%[acts]all%surfacen2%#cmessYou now have the %objn1%.#objlocn1=501[end]

[start]get %objn1% off %objn2%#objlocn2=here#objlocn1=%surfacen2%[acts]cmessYou now have the %objn1%.#objlocn1=501[end]

[start]look on %objn2%#objlocn2=here[acts]lookonobjn2[end]

[start]look on %objn2%#objlocn2=here#anyobjs%surfacen2%[acts]cmessLying on the %objn2% is:#listobjs%surfacen2%#else#objlocn2=here#notanyobjs%surfacen2%[acts]cmessThere is nothing standing on the %objn2%.[end]

[start]drop %objn1% on %objn2%#objlocn1=here#objlocn2=here[acts]cmessYou put the %objn1% on top of the %objn2%.#objlocn1=%surfacen2%[end]

Of course you might need to add in some more condition checks and restrictions etc... according to your game mechanics.

Regards,
Phil.

Hi Phil,

I like how you coded gareth's new feature of being able to put things on another object and was wondering if it would be possible to introduce the same idea as 'showinv' in script 1 where the contents of the surface object are displayed automatically when the object is listed?

e.g.
You are in your local pub.
You can see:
Bob the barman
...Bob the barman is carrying:
......a bottle of beer
the table
...On the table is:
......a plate of food
......a knife
......a fork

Cheers

Mark

AH! Thats an interesting one Mark.
Is it something that you see as being a globel switch/off or would it be a location specific command where we set what can be seen "on an obj" in "here" or used with something like "or¯room=X etc etc"

Or is it required as an option for all three plus others not mentioned here

Either way Phil, me thinks its a busy day ahead lol

gareth.................

Hey Gareth,

I just reckoned that you should have the option - to make it a bit more customisable. Plus I thought that objects placed on certains objects that are easily viewable, like tables, shouldn't really need to be looked on ... the same way you don't need to examine a room just to see a door. The door is just there to be seen as soon as you walk in to the room, and so are the objects sitting on the table.

Just my two cents (or should that be pence!) for potential tweak to a great idea, good one!

Cheers

Mark

Well you could always list the objects on a surface object when the surface object is examined I suppose.....

However, I like Mark's idea of showing the objects residing ON an object being listed at the location description too.
Maybe I can add it in to the "showcontents" method of listing?

I'll have to think a little about this one.

Phil.

Quote :

I like Mark's idea of showing the objects residing ON an object being listed at the location description too.
Maybe I can add it in to the "showcontents" method of listing?

Agree -as I said abov. The concept opens up new diamentions to the location descriptions and, I feel, gives the descript' a more natural feel. Plus with ability to vary the use of the command can/may make puzzle making making more intersting especially as there are only so many ways you can describe a location within reason. This opens that description up still further.

Look forward to see what if anything can be done - good one Mark.......

I'm lovin' the concept of being able to place objects on to the surface of other objects.

And that got me thinking ... would it be possible to be able to put an object behind another object?

Maybe use the location 2000 + the object number (instead of the 1000 used for surface) ...

I did a similar thing by having the curtain (in my example below) as a container object but then the objects would be listed as inside the curtain, rather than behind it, but if too much trouble I could certainly live with it.

Just thinking out loud

(Following modified from Phil's explanation of surface functionality)
*NEW actions:
lookbehindobjn2 - same as lookbehindobj
lookbehindobjn1 - same as lookbehindobj but for object noun1
listbehindX - same as lookbehindobj but for object number X

*NEW condition/action coding tags:
%behindn1%
%behindn2%
behindx

eg:
anyobjs%behindn1% - are any objects BEHIND object noun1?
eg:
listobjs%behindn2% - list objects BEHIND object noun2

e.g.

You are in a bar.
You can see:
... a curtain
...... Behind the curtain is:
......... a broom
......... a bronze key

... a cupboard
...... in the cupboard is:
......... some food
......... a pint glass

... a table
...... on the table is:
......... a bottle of beer
......... a bottle opener

LOL Mark I suspect that poor old Phil is sitting on the edge of his office seat rocking back and forth cursing us to hell........

This MUST be the biggest posting in this section ever simply because of the "Well, if we can do this is this possible to do that............that..........that and that.".

and then if we can do that can we make bigger, better faster further lol

Being a quality manager I love it when the development thought process wheels start grindig away and you look at the face of the people that have to make the machine to do the job as they grow grey, then white and the shaking starts, then the stuttering lol

Phi! Its only suggestions afterall lol dont stress!

Gareth

Well I don't think we should get fixated on having too many lists...

As I see it "Behind the <object> is:" type of listing might be going a step too far. I mean, if the player is able to see the object in the room then why not just make it an object in the room itself - and also remember you're not really supposed to be able to see if something is BEHIND or UNDER something else. The standard way is to implement the discovery of such objects in a puzzle would be along the lines of Response entries like "look behind <object>" or "look under <object>" or maybe "examine <object> which would then create the hidden objects into the room and thus make them found and now available for interaction with the player. This is easily done in TAB.

Also if you are going to put objects to special locations 2000+ as being behind something then the normal standard "get <object>" and "get all" default commands would not take those objects as those commands only operate for objects in the player current room, so the player couldn't easily take those objects even though they are listed as being there (albeit behind something else) ; it could be difficult to make a

>get <object> from behind <object>

type of command and I don't honestly think it really necessary or worth it in the long run for something that might only be used once or twice in a game.

Again to implement it I would have the same kind of limitations as with "look on <object>".

Phil.