Marking locations and teleporting back

I wrote two small scripts a few weeks ago, perhaps somebody may find them interesting, they add a new feature to the game - marking locations and teleporting back to them (think Morrowind).

Here's an example mod. Put the file into your Arcanum folder and it should work on any version of the game, on any save. In this mod, the scripts overwrite the ones used for the Mysterious Gem (the Naked Halflings' quest) and Whysper's Gem. The first one marks a location (a tile) and the second one teleports the player to it, at any time.

There are some limitations, though. Since it's not possible to get a map's number through scripting, I made it so you can mark locations only on the main map, no dungeons (the gem will play a "wrong" sound). I've also disabled the use of the gems in the Void, for obvious reasons. I didn't bother to make checks for the IOD, T'sen-Ang and similar places though, you may add them if you wish, it's very easy to do. Also, the gems don't check for Magic/Tech aptitude.

You may use this in your mods, but be sure to give me a credit.

 

Thanks!

 

Good lookin' out, Drog. I hear you about the lack of functionality in scripting, and I don't blame you for not scripting these items to work on all maps. Going through all the teleport scripts - and NPCs that teleport the PC - would be a pain in the ass. Hopefully this will help people learn about scripting, as well as being functional.

 

Mmm? Why would you do that?

My script just stores current X and Y in global vars, and then teleports the PC back to them.

 

Just to add functionality. You could use a third gv to record the map number, so your teleport script could teleport the PC to a location on any map. As far as I know, the only way to effectively do this is to set the gv for this value whenever a script teleports the PC from one map to another, and change the proto for the scroll of exiting to do the same (using a 4th gv, which stores the previous value of the 3rd gv). The teleport spell only works on the world map, right?

Of course, it isn't worth the work. I tend to overscript, though, which is why I commented on it. It's also the reason my mod isn't done...

 

This is just... stupid. You do realize how many teleport scripts are there? There are at least 200. And then there are also jump points, to which you can't attach any scripts.

A possible solution with current script commands would be to make checks for areas. When you try to run the script in a dungeon, it would make checks for a list of possible areas. E.g. you're in Qintarra -- the script sees that the area number is 6, and sets the third global var to 5018. But then again, this is still flawed, since several maps can have the same area number (however it still may be possible to distinguish some of them by using size checks, etc).

Anyway, unless somebody can be bothered to add an extra script command for checking a map's number, there's no real solution. I mostly made this script as an example, just to show how the command can be used, I don't plan to continue working on this.

 

I don't believe I actually said this should be done ("I don't blame you for not scripting these items to work on all maps"; "Going through all the teleport scripts [...] would be a pain in the ass."; "Of course, it isn't worth the work.") As I said, I only commented on it in the first place as one way this might be done, IF it were worth doing. However, I'd be happy to keep discussing it in a theoretical sense. You said that the reason you did this was to demonstrate how it might be done, and I imagine that it not only helps modders see the mechanics but also could make some people think about how a problem might be solved with scripts. I only brought it up in the first place as a comment on why making it work for only the world map was a practical idea, but I'm continuing so we might discuss how it might be done.

I don't think this is viable, and it might not actually be possible. Consider that areas work not only for the local maps (5018 and 5019 for Qintarra) but for the world map. Tarant, Caladon, and Tulla all have about a dozen maps with the same map area. Taking size checks into question, the main map can be distinguished, but the smaller maps can't. The only way to use area checking would be to add a new entry for each of these maps into gamearea.mes so it appears that the player is in the correct area of the world map while inside, but in addition to the problem of adding so many new entries to this file, it would alter the PC's ability to ask followers about an area. Those follower dialog entries could also be changed, but it's one more layer of difficulty. However, unlike follower dlg files, there isn't much reason for there to be multiple versions of the teleport scripts out there on the internet, where there could be conflicts between different mods.

You're right about this - I hadn't considered it. However, since stepping on a tile with a jump point will also trigger the tile script on that tile, all adjacent jump points can be covered by adding a tile script on top. It can be just one script file, with the last 2 digits of the map number being stored in one of the counters for that tile script. This would be the easiest part of the changes, whether using your approach or mine.

In either case, there's no way to generalize from the particulars and find an easy way to check the map number. IF the map number had to be checked, it's either a new script command - and I'd lean on your experience, not mine, as to whether this is actually possible - or altering quite a few files. There's no real way to contain this whole problem within the two scripts attached to the gems.

 

Even if somebody adds global var changing command to all 200+ teleport scripts and replaces all jump points with tile scripts there would still be many problems. E.g. let's say I walk into a dungeon and a teleport script sets a global var. I then cast the teleportation spell and exit the dungeon without changing this global var.

Anyway, the discussion is pointless. It just can't be done without an extra command.

 

As far as I know, you're one of the two people who have altered the .exe beyond a no cd crack. How much work would be required to add a new script command, whether this one or another? Is this even remotely feasible?

 

Should be possible, quite hard to do though.

 

I haven't delved into scripting yet. Still learning how to manipulate the .mes files. But my thought is, would it be possible to have an item just mark a location on the world map and use the regular teleport spell to return to it at a later time?

Possibly by adding a new location with null values in the x,y co-ords and having the script for the "marking" item supply those, and place a "Known Location" marker on the world map for use by the Teleport spell.

just a thought. Maybe I'll look into this once i progress into scripting.

DMCain

 

A good thought, but unfortunately no. The values for an area must be added to gamearea.mes during the modding process; no script can change the values. You could make a red dot appear anywhere on the world map, and make it so teleporting there sends you to the marked location, but you won't be able to decide where that dot is once the game starts.

 

Gravedig, I know, but this is Modding and Scripting, after all.

Solved the problem, and all it requires is one script and a couple dozen .mob files!

When one is teleported to a map, one's PC exists for an almost infinitesimally small time at sector 0. If one NPC is added in sector 0 for each map, the FHB script attached to each one can set our gv for map number. For example, if our map number gv is #999:

0. Global Variable 999 = Counter 0 + 5000
1. return and RUN default

Counter 0 is set to the map number when the script is attached to our NPC. Beyond that, I haven't bothered to find out if followers will attack it, but if so, it can just have its invulnerable flag set, and therefore wouldn't attack back either, even if this did happen.

So, it's not nearly as hard as we thought it was. Just a bunch of naked female NPCs and a two-line script.