Author Topic: Problem with waypoints using relative paths (Read 1310 times)

Lippy

We know relative paths should be used if we can help it, and this is where the potential issue starts. Let's say we want a waypoint in a mob, and the mob needs to move from one map to another. In this case, the second map is in a different directory. So let's call the map the mob spawns in /map1_0000, and the second map where we want the mob to move to /more_maps/map2_0000.

With relative paths, we tell the mob to move to more_maps/map2_0000. When the mob arrives there, we want the mob to return to its home map. This is where we start having problems. You would think the second waypoint (which is also in the mob's inventory) would need to point to map1_0000 in order to tell the mob to return to that map, right? Wrong. After the mob has reached its first waypoint, the mob and by extension the second waypoint is now in the second map. So in order to get the mob to return to the first map, the waypoint needs to point to ../map1_0000.

This a bigger problem than it seems. What if the waypoint has a range that can overlap those two maps? If the mob is satisfied with being at the first waypoint and the second waypoint is triggered while the mob is in the wrong map, the waypoint will then break and will produce a BUG message in the server.

We already have an example of this problem in the maps. The mugwumps north of Stoneglow have waypoints to a map in another directory. I think the original mapper used absolute paths for these in order to workaround this issue. It is however generally not acceptable to use absolute paths in waypoints, so now we end up at a bit of a stalemate over what's acceptable and what's not.

Anyway, I think the behaviour of waypoints should change because of this issue. If a waypoint is placed in a mob's inventory, it should always behave as if it is always at the spawn point of the mob. That way, waypoints would always be fixed objects. Beacons already behave like this as it has its own issues if it is a moving object. With this change, we can use relative paths without any problems.

smacky

I don't offhand know why they were absolute paths.

But whatever, they were at first waypoints to beacons rather than waypoints to map,x,y.

This is because (a) I prefer beacons anyway and more importantly (b) the waypoints cross map boundaries.

With beacons, if the map is not loaded the beacon will not exist and the mob will not move.

With map,x,y, I'm not sure what will happen, but I don't believe it is handled so cleanly.

This is based on the info in types.xml:

Quote

<attribute arch="race" editor="destination beacon" type="string">
Name of a beacon to target. Overrides destination map, destination x and
destination y. This only works if the beacon can be found (i.e. it is on a
map that is loaded in memory), so using a destination map might be a better
idea if crossing one or more map tiles.

Leave this empty if you want to use an explicit target coordinate (map, x, y).
</attribute>

EDIT: LOL Maybe this is why they weren't beacons subsequently? Because I misread types.xml the same way then as now.

But anyway, yes making the wp path relative to the spawnpoint rather than the mob might be the best solution. But can spawnpoints move? For example, a script might SetPosition a spawnpoint, meaning it might appear on a random map. In this case, a relative-to-spawnpoint path would be useless (as would relative-to-mob as now); the path would have to be absolute.

But this is where beacons win over map,x,y: no worrying about paths at all.

Lippy

Hmm, I see your point. Looks like it's beacons ftw then. Probably should document this, in case someone else falls into the same trap.

EDIT: Fixed the mugwump waypoints. It's all good, no more warnings are being spit up about that anymore.

Author Topic: Problem with waypoints using relative paths (Read 1310 times)

Lippy

Problem with waypoints using relative paths

smacky

Re: Problem with waypoints using relative paths

Lippy

Re: Problem with waypoints using relative paths

Related Topics