Tinkering with fast travel, question about ocean pixels

Discuss coding questions, pull requests, and implementation details.
Post Reply
Ramesside
Posts: 2
Joined: Sat May 04, 2019 9:37 am

Tinkering with fast travel, question about ocean pixels

Post by Ramesside » Sat May 04, 2019 10:42 am

Hi,

Some friends and I are working on a mod idea where we add random encounters (including positive ones) to the game to spice up wilderness exploration, resting, and fast travel. We wanted to have a random chance to interrupt fast travel, and we felt it would be a good way to add depth to the cautious / reckless pace and so on (as in, those choices would affect the chance of an encounter occurring, as well as what kind of encounters might occur). But we realized that the fast travel system assumes that you go through the ocean, even if you are not using a ship. As a result, we decided to attempt to modify the fast travel system to avoid bodies of water, and to have a "smart" path that is at least somewhat similar to what a real person would travel along. The algorithm is (theoretically) pretty straightforward -- we make a vector to the desired destination, check if that vector intersects the ocean, and modify the angle of the vector if so. We repeat this process until the vector goes on land instead. It's designed in such a way that the new vector will hug the coastline, for the most part (because the angle increments are small).

However, we've run into a bit of a problem. In order to determine if the vector hits the ocean, we pass in each map pixel along the vector to the MapsFile getClimateIndex function and compare it to the ocean value in the Climates Enum to determine if we are travelling on ocean. For debugging purposes, we also added a check on the ClickHandler function in DaggerfallTravelMapWindow to see if the pixel being clicked is considered ocean. We offset the position by the respective origin stored in offsetLookup, and in many cases the spots that we can visually see as being ocean are correctly identified as ocean when clicked.

But we've noticed, with the ClickHandler debugging, that some of the map pixels that are visually on the ocean are not designated as such*. Understandably, this creates some bugs and unexpected behavior with our algorithm. We were wondering, would it be a simple matter to change the contents of the .pak file ("CLIMATE.PAK") to accurately reflect the extent of the ocean? If so, how might one do this? We don't know how to edit the .pak file, but we figure one could write a program that checks the RGB values of the pixels in each map image and says that it's ocean if it's blue. Then, we could maybe use those pixel locations to overwrite climate.pak with the updated ocean information. But this depends what climate.pak is based on, visually -- for example, is it based on the zoomed out world map?

*We are assuming that the information from the ClickHandler correctly reflects the status of the map pixels.

Additionally, would a functional fast travel pathfinder that avoids ocean be something that is aligned with the goals of the project? It's my understanding that the original Daggerfall also assumed that the player walks on water / swims when calculating travel times across the bay. Immersion-wise, I don't think this makes a lot of sense, but then again, maybe we don't want to mess with the feature in this way. Anyways, we wanted to implement this for our mod, but obviously we've been editing the source code directly, which makes it not a traditional, downloadable mod perse, unless we had some sort of code injection / script extender utility.

Thanks!

Ramesside
Posts: 2
Joined: Sat May 04, 2019 9:37 am

Re: Tinkering with fast travel, question about ocean pixels

Post by Ramesside » Sun May 05, 2019 10:36 am

Actually, we found a bug in our Clickhandler pixel checking, which we've fixed, and we found that the ocean pixels are accurate. So nevermind about that :D But we're still curious to hear if a working version of this would be desirable for the project. And we're also wondering how a mod that needs to edit the source code directly would work. Is it possible to extend functionality in a convenient way for users to download and still be able to go back to the original version? I.e. if the mod were disabled, the script extension wouldn't take effect.

User avatar
King of Worms
Posts: 2347
Joined: Mon Oct 17, 2016 11:18 pm
Location: Scourg Barrow (CZ)
Contact:

Re: Tinkering with fast travel, question about ocean pixels

Post by King of Worms » Sun May 05, 2019 4:49 pm

Hi, welcome! I appreciate your intentions :D
For the specific questions like this, Id suggest contatcting Interkarma, hes the man behind all of this. Maybe ping him a PM with this post. He will know, or redirect to you other ppl who will help.

Be well, good luck, have fun :)

User avatar
Interkarma
Posts: 4863
Joined: Sun Mar 22, 2015 1:51 am

Re: Tinkering with fast travel, question about ocean pixels

Post by Interkarma » Sun May 05, 2019 11:37 pm

Welcome to the forums. :)

I like your mod idea. It puts me in mind of the Fallout 1 & 2 fast travel system where player sees their progress path over overland map with a chance for random encounters to interrupt travel. I think something like this could really work in DFU.

Ramesside wrote:
Sun May 05, 2019 10:36 am
But we're still curious to hear if a working version of this would be desirable for the project.
For the base game, our main goal is to emulate classic's behaviours and travel times. I'm fairly happy with where this is right now and don't wish to change it in the foreseeable future. Any changes will need to be delivered via mod system.

Ramesside wrote:
Sun May 05, 2019 10:36 am
And we're also wondering how a mod that needs to edit the source code directly would work.
It's not really feasible to edit compiled C# from a mod. For the mod system, we have an integrated C# compiler that builds your custom scripts and executes them within the game. From there, your code can interact with the core game in many ways.

You generally change core behaviours in DFU either by addition (e.g. add new components to player/world that work alongside existing behaviours) or by substitution (e.g. swap out an object/behaviour for one of your own). In several cases the core will expose hooks for mods to do their work within base game. Examples are adding a new terrain sampler, registering quest actions, or registering new magic effects.

For your mod particularly, swapping out the fast travel UI would be essential, as fast travel is delivered completely through the UI system. My future plans for modding UI windows is to work through substitution - either a new DagUI window or a fully custom uGUI window. This would allow modders to completely overhaul the UI if they wanted to, which is also helpful to localisation efforts.

DagUI is built to emulate classic only. The UI windows are fairly monolithic with presentation and behaviours all part of the UI code. This is fine for the core game which only has the one job of working like classic. But a more robust UI mod might want to split these behaviours out from the UI code. Once you're able to replace the classic UI, you'll be able to re-implement this in any way you wish to deliver custom behaviours.

Post Reply