Adventure Game Studio

AGS Support => Advanced Technical Forum => Topic started by: InCreator on Thu 15/09/2005 04:16:32

Title: SUGGESTIONS: Show areas when setting walk-to point / Global object names
Post by: InCreator on Thu 15/09/2005 04:16:32
1) When setting walk-to-point for hotspots, walkable areas could be seen in some form, even outlines if nothing else.
It's hard to set a walk-to if you can't figure out where walkable area is. And characters won't act very smart in game if the point's outside walkable area. It's nothing special, but I find very little use to walk-to-points if i have to character.walk by script every time anyway.

2) oObject.Visible, etc object-related variables can't be changed outside room script.

But if I need to set it from character interactions, like after talking to character - turn some object on/animate/whatever? It's quite a pain to set GlobalInt only, then check it from room's repeatedly_excecute, then perform the thing... etc. Especially, if there's more than 1 object-related thing which comes from character's interactions.

Can't AGS recognize object names from all rooms (in future)?
Let it compile, but generate error when character isn't in that room (with used object) or something... current way to work around in such cases is too primitive.
Title: Re: 2 suggestions.
Post by: strazer on Thu 15/09/2005 04:30:38
Quote from: InCreator on Thu 15/09/2005 04:16:32But if I need to set it from character interactions, like after talking to character - turn some object on/animate/whatever? It's quite a pain to set GlobalInt only, then check it from room's repeatedly_excecute, then perform the thing... etc. Especially, if there's more than 1 object-related thing which comes from character's interactions.

That's what the OtherRoom script module (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=20650) (or plugin (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=14203)) is for.
Title: Re: 2 suggestions.
Post by: Gilbert on Thu 15/09/2005 08:03:33
Quote from: InCreator on Thu 15/09/2005 04:16:32
1) When setting walk-to-point for hotspots, walkable areas could be seen in some form, even outlines if nothing else.
It's hard to set a walk-to if you can't figure out where walkable area is. And characters won't act very smart in game if the point's outside walkable area. It's nothing special, but I find very little use to walk-to-points if i have to character.walk by script every time anyway.
Hmmmm, maybe some sort of semi-transparent (so you can still see the current hotspot area gray areas which represent the non-walkable areas ? I think this definitely can help.


Quote
2) oObject.Visible, etc object-related variables can't be changed outside room script.
blah bla bla
Can't AGS recognize object names from all rooms (in future)?

I think the problem is, doing this may mean big changes to how the engine works, so I'm not for it.
Currently the engine doesn't care about rooms until they're loaded, when you start a game and say, room 5 hadn't been visited yet, no information about room5 is stored in memory, this provides fast access and flexibilities.
Notice also that for most resources (that includes room files) if in the compiled game's folder there's a separate file, the separate file will be loaded. For example:
You released a game, now you want to add a room say, 107 (which was not in the original game), which can be entered from room say, 50 (which was in the released game). So you created room 107 and made changes to room50.crm and compile a new game. Now, provided that you didn't change anything in the global script, or added any sprites, etc. (only changes are the 2 room files), you can just upload the 2 room files, so people who had downloaded the old version already can just download these 2 rooms and put them in the game's folder as a patch.

If the engine is made to be able to access stuff in a room from somewhere else the above flexability is not easy to acquire. Moreover, doing such change would mean at game start the engine needs to scan the resource files for room info (slow) or need to load up some kind of room data index which was created in compile time (makes compiling slow, as it need to look up for info from all the included room files).

Edit: other benefit for the current implementation is that you can reuse object names in different rooms. If you're just using oDoor, etc., it'd be difficult to tell where it's from, unless it's something like room[12].oDoor, or room[12].object[4] (well I think the former is much less practical, as you need to load up info from all of the rooms to refer to the names).

So, just do it the conventional way (or use the module) as Strazer said, and in my opinion setting up a variable is simple enough, which is my prefered way than using modules.
Title: Re: 2 suggestions.
Post by: SSH on Thu 15/09/2005 14:15:27
Quote from: InCreator on Thu 15/09/2005 04:16:32
1) When setting walk-to-point for hotspots, walkable areas could be seen in some form, even outlines if nothing else.
It's hard to set a walk-to if you can't figure out where walkable area is. And characters won't act very smart in game if the point's outside walkable area. It's nothing special, but I find very little use to walk-to-points if i have to character.walk by script every time anyway.

Hear hear, although maybe you'd want to toggle this

Quote
2) oObject.Visible, etc object-related variables can't be changed outside room script.

But if I need to set it from character interactions, like after talking to character - turn some object on/animate/whatever? It's quite a pain to set GlobalInt only, then check it from room's repeatedly_excecute, then perform the thing... etc. Especially, if there's more than 1 object-related thing which comes from character's interactions.

Can't AGS recognize object names from all rooms (in future)?
Let it compile, but generate error when character isn't in that room (with used object) or something... current way to work around in such cases is too primitive.

I'd like to point out that you can do object[0].Visible=1; and similar in the global script. It does mean you need to know object number, but you can set up an enum or something..
Title: Re: 2 suggestions.
Post by: Scorpiorus on Thu 15/09/2005 15:12:08
Quote from: SSH on Thu 15/09/2005 14:15:27I'd like to point out that you can do object[0].Visible=1; and similar in the global script. It does mean you need to know object number, but you can set up an enum or something..
InCreator:
Yeah, just make sure the object you are refering to by number does exist in the current room.

[edit]

Example:

global script function:

// object #1 must exist in a room of number 1, 7 and 10
if (player.Room = 1 || player.Room = 7 || player.Room = 10) {
Ã,  object[1].Visible = true;
}

// object #0 must exist in any room
Ã,  object[0].Visible = true;

Sometimes handling similar objects from within the main global script can really make things easier but as a general rule you should refer to them by their script O-Names because it ensures you're accessing the correct object. Unlike with refering to by their numbers -- you can, for instance, remove object[0] from a room and then object[1] will take its place (ie. become object[0]).
Title: Re: 2 suggestions.
Post by: Ishmael on Thu 15/09/2005 15:17:17
I think I suggested ages ago somewhere that the objects could be handled like room[num].object[num], so you could have done ObjectOff(room[rLOUNGE].object[oCARPET]); anywhere in the game... But I don't remember where I did.
Title: Re: 2 suggestions.
Post by: Kweepa on Thu 15/09/2005 20:24:14
Quote from: Ishmael on Thu 15/09/2005 15:17:17
I think I suggested ages ago somewhere that the objects could be handled like room[num].object[num], so you could have done ObjectOff(room[rLOUNGE].object[oCARPET]); anywhere in the game... But I don't remember where I did.

You mean like this?

OtherRoomObjectOff(ROOM_LOUNGE, OBJECT_CARPET);


Quote from: strazer
That's what the OtherRoom script module (or plugin) is for.

:=
Title: Re: SUGGESTIONS: Show areas when setting walk-to point / Global object names
Post by: strazer on Thu 15/09/2005 20:26:08
1.) I think tracker entry "Display room areas semi-transparent (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=179)" covers this. Feel free to add your comments.
Title: Re: SUGGESTIONS: Show areas when setting walk-to point / Global object names
Post by: Pumaman on Thu 15/09/2005 21:54:30
1. I can see why you'd want this, but showing walkable areas in the hotspots screen could be a bit confusing.

2. As SSH points out, you can use the global object[] array to access room objects from the global script, but it's simply not practical to have the O-Names available.
What if you have an "oDoor" object in two different rooms? That's quite likely and I wouldn't want to have to make all object names globally unique just so that the global script can see them.
Title: Re: SUGGESTIONS: Show areas when setting walk-to point / Global object names
Post by: SSH on Thu 15/09/2005 21:58:00
A thing I think i did in Pixel Hunt is to call a global function on room enter, passing some object pointers:

so in before_fadein interaction:

global_func(oElevator, oFloorNum);

and...

function global_func (Object *a, Object*b) {
  oElevator=a; oFloorNum-b;
}
Title: Re: SUGGESTIONS: Show areas when setting walk-to point / Global object names
Post by: Scorpiorus on Fri 16/09/2005 16:30:51
...which is actually even safer than using object[] directly.
Title: Re: SUGGESTIONS: Show areas when setting walk-to point / Global object names
Post by: Wretched on Fri 16/09/2005 20:03:47
Wrt showing walkable areas as tranparent in the editor, I would prefer some keyboard shortcuts , e.g. keys 1,2,3,4 to change between area so you can keep the mouse still when switching areas.