Solved: Problems with WalkTos?

[Cerno]

A general question:

I think I read somewhere on these forums that Hotspot WalkTos should not be used as there can be problems with them.
Is anyone aware of this or did I remember this incorrectly?

I was thinking that generally it would be a good idea to use WalkTos more and "magic numbers" in your code less, since you could easily change a WalkTo once without having to adapt your code in multiple places. So what is the preferred way to do this?

The following does not really belong here, but as it is related to the above, let me dump it here anyway: 

Two ideas that are certainly not new, so I was wondering whether there is some consensus on whether they make sense. Are there any plans to do anything like this?

1) Define arbitrary points in the room GUI:
I think it might be neat if you could place points in the room and name them, so that in the game script you can use the names instead of manually entering coordinates. It would visualize the way scripted scenes work better and simplify the process of defining and changing positions. You could also immediately see whether a coordinate that you want to use in on a walkable area or not.

2) Access other rooms' information:
As I understand, currently all objects, hotspots, regions and so on are only accessible via the current room's script.
I am sure it has been discussed before, but wouldn't it be really useful to be able to access this outside the room?
It would give the chance to define a Walkto point of a door. The when you can call the ChangeRoom function you could use the Walkto coordinates to put the character right next to the door without having to fiddle with the coordinates manually.
It would also allow for object manipulation. If a character turns on the music in room A that could cause a vase to fall down in room B. This can be scripted via global functions, but the direct access would be so much simpler.

[geork]

Hello Cerno

I just saw this in passing, so I'll offer some thoughts and hope they are relevant

1) There is a bit of a middle ground: in the room editor, you can middle click on the part of the room you are interested in and select 'copy coordinates to clipboard' (basically copy the coordinates), which you can then paste as normal anywhere you like. It's not the same as having some points mind, but it's something.

2) You can't access objects/hotspots/regions by name from an external script (well, you can't ever access a region by name) but you can access them via their index and type. Something like:

Code: AGS

int x = object[1].X //Get the X coordinate of object ID 1

    Of course, this style will only affect/effect the specific object in the currently loaded room, but being able to access any object in any room isn't practical. Not only would every object now have to have a unique name, but every room (I imagine) would have to be loaded in at all time for changes to take place consistently.

I hope my thoughts have proven useful

[Khris]

While it's not possible to place points in the GUI, you can write a few functions that let you manage your own points.
Something like:

Code: ags

// game_start
  AddPoint(3, 234, 123, "left library entrance");

// some interaction
  player.WalkTo("left library entrance");  // walk to coords
  player.Reposition("left library entrance");  // teleport to room, coords

Regarding the other point, there's a (pretty old) module called OtherRoom which allows precisely that. Of course, all it does is keep a lot of variables and change stuff after the room is loaded using on_event/eEventBeforeFadein.

[Cerno]

@geork:
Thanks for the middle click, I did not know that. It will be helpful for the future.

About accessing other rooms' objects, I think it would be very manageable from a scripting point of view by introducing a notation like this: room4.oVaseBroken.Visible = true;
The old notation oVaseBroken.Visible = true would still be valid for the current room of course.
I don't think it would be too troublesome from a technical point of view, since the game will have to keep track of all the room states anyway, so modifying one room's state from another room does not sound like too much of a problem.
Note however that I did not have a single look at the source code of AGS, so I have no idea how difficult that would be to implement in reality.

@Khris: Useful tips as always, thanks
One comment on this, I think would like enums better instead of strings since strings are quite error prone. One typo will cause a bug that you only find once you interact with a specific object while an enum typo will cause a compiler error right away. Of course it will be a little inconvenient to add an enum definition to each room first.

So finally, any ideas on the WalkTo issue from the top? Safe to use? Or should I avoid them?

[Cerno]

Sorry for bumping this, but I guess my original question got lost in the discussion about custom points and accessing other rooms' objects.

So, how about hotspot and other WalkTos? Safe to use or steer clear of them?

[Khris]

Depends.
I always try to implement general solutions, and since objects and characters don't have WalkTo points, using them is a no-go for me.
On the other hand you can calculate walkto points for those, so you could automate approaching something depending on the location type.
It's not possible to change walkto coords during run-time though, which again, makes using them a double-edged sword.

[Cerno]

Okay thanks, that clears it up for me.

I thought there were some glitches connected to those but I can't remember where I read it so I might have misunderstood the context.