Travel Map

[Rusty]

Following on from the discussion at the NWN2 Team meeting, I talked to Sand about his (scripted and more detailed) implementation of a travel map. If Sand can be given the information he requires, he has offered to make a proof of concept for TSM. I have added him to the 03 UG to facilitate this.

Sand, if you can post your requirements here, I'm sure AL, Rick, or Wynna can meet them.

Thanks everyone.

[Sandermann]

Hi all:

ok, first off the travel map that is currently used, though based on my original idea, falls pretty far short of what I originally intended. The map system I worked on back when NWN2 first came out provided scopr for random encounters, different terrain types, hidden POI's etc etc.

In order to create a new one for TSM, I need the following:

As detailed a map as can be provided of the server area. If the map doesnt show things like elevation, terrain types, etc then I need to know what goes where (sorry but I just dont know the area very well ). The travel map is a 3d representation of this flat map, so if theres anything important valley's or mountains I need to know where they have to go.

If its not on the map, I also need to know the scale of the server area. The travel map system slow character movement to provide a more realistic representation of how quickly a character can cover the distance depicted and I can do that without knowing what area the map actually depicts.

I need to know how you want POI's to be represented. The method I use normally is to use a relevant scaled down placeable to represent a POI (House for a village, that kind of thing) but any any placeable can be used for the purpose. Signpost placeables are one that springs immediately to mind.

Depending on how many terrain types are on the map, a number of generic areas for random encounters and for PCs to use when they drop out of the travel map away from a POI are needed, I can make some to proove the concept, but I cant do many as I dont have time , in the past ive found that around 4 areas per terrain type are sufficient. More if its a terrain type used often in the map, and vise versa.

The map system also requires some minor custom content, mainly new "grass" textures to represent trees. This adds only a few kB to the haks and reduces the load the area places on the server massively.

I will get cracking as soon as I get my next day off work, which should be early next week sometime, and I expect it will take me a good week to get something presentable completed.

[Rick7475]

OK, I will answer as best I can

Here is the map:

http://www.thesilvermarches.net/uploads/003_sept19.jpg

The towns and major settlements going in are as follows:

Fourthpeak
Settlestone
Rivermoot
Winter's Edge
Herald's Holdfast
Quarryvar
High Hold
Rauvinwatch Keep
Silverymoon
Khelb (part of Silverymoon Pass)
Citadel Felbarr

Some will be linked directly without using a travel area or map. There will be a main corridor of travel and then outlying areas accessible only through the travel area or travel map.


The linked areas are as follows:

(East to West)Herald's Holdfast (Moonwood) - Quarryvar (Moonwood)

(East to West) Rivermoot - Highway Area - High Hold - Highway Area - RauvinwatchKeep - Silverymoon - Silverymoon Pass



Here are the jumping off point areas to the travel map


Rivermoot - Fourthpeak (mountains and plains)
Fourthpeak - Rivermoot (palins and mountains)
Fourthpeak - Settlestone (mountains)
Settlestone - Fourthpeak (mountains)
Herald's Holdfast - Winter's Edge (plains)
Winter's Edge - Herald's Holdfast (plains)
Winter's Edge - Fourthpeak (plains and mountains)
Fourthpeak - Winter's Edge (mountains and plains)
Winter's Edge - Herald's Holdfast (plains)
Silverymoon Pass - Citdel Felbarr (mountain)
Citadel Felbarr - Silverymoon Pass (mountain)


My scale is very rough, but on the map, traversing the width of a square is between 3-4 24X24 areas, again, that is very rough. So, travel from Rivermoot to Fourthpeak might be 4 - 5 24X24 areas if it were to scale. If you can simulate that with the travel areas that might work. However, whatever you do is fine

Thanks for doing this!

[AcadiusLost]

I should be able to get some generic encounter areas from the Exodus folks, as part of our exchange of resources and such. They have been eager to get travel map encounters and other scripted support in for some time, and the effort can benefit both PWs.

I'll be in touch about the area templates. I should also be able to handle ACR event hooks (such as the Rest Key intercept) for the project, when we integrate Sand's map system into an ACR framework.

Questions for Sand:
-Do you need persistency at this stage of development?
-Do you want to build in a demonstration module with just a few TSM areas?
-would be be convenient to conduct discussion about the system itself in the NWN2 ACR forums, which are visible and postable to most NWN2-involved folks?

[Sandermann]

-There is no need for persistency at all, beyond location saves. The travel map system itself deals with it on_area_enter.
-I will build in a separate module anyway, if only the core system is more readily "plug-and-play", I can include a sample of generic areas to prove the concept that can be used later in the live version.
-It may be, though I do not have time to track discussion of this project across multiple threads, for me at least it would be more convenient if it was all in one place

As for hooking into things like the rest button, is it necessary? I say this because it is easy to accidentally hit a button, and chopping in and out travel map is quite resource intensive. imo it would be better to simply prevent rest on the travel map and have players manually drop to a generic area to rest. Its up to you though

[Rusty]

Moved to ACR.

[Teric neDhalir]

Hi,
Any progress on this? I need to get encounters squared away for 011's scaled-down areas and if I have to write it it's not going to be very elegant. Srsly.
TnD

[AcadiusLost]

I haven't heard anything on it since Sanderman's posts on the topic. I've said that I will code it once I've got my dissertation submitted, but that's going to be a while longer still.

If you've got a burning need to start into it on your own, I can find and forward the discussion and specs we'd wanted to go with, as a starting point. Just let me know via PM or email if you're up for it- otherwise patience is in order, since I'm not starting into any new big scripting projects until I have other matters under control.

[Teric neDhalir]

AL I'm certainly not volunteering you for anything, but I would like to try and get this moving if possible. If there is any documentation of what was discussed I would be keen to see it.
Thanks
Teric

[Teric neDhalir]

Update to the travel map thing:
I've been working on a clunky implementation of this and have made quite a bit of progress. I have an encounter system working (caveat - I've only tested it as a single player from my own box), which has a pseudo-heatbeat runing in the travel area(s) that periodically checks PCs/parties to see if they are within trigger areas that have a terrain type and encounter chance. On an encounter firing the PC(s) are moved to an area suitable for the terrain where there are ACR day and night spawn points with group scripts. This all seems to be OK so far, but I have the following problems which I need help or guidance on:

1) I have a counter running in the encounter area counting the PCs in and out so that a) the main script knows if the encounter area is "engaged" and so doesn't send any more PCs there and b) so that the spawn point is refreshed when the first PC of an encounter enters the area and disabled when all PCs have left. I'm not having any success at the moment with turning the spawns on and off. I've looked at the various functions in acr_spawn_i but they're beyond my understanding. What I have at the moment for the OnEnter script includes

if (GetLocalInt(OBJECT_SELF, "sjc_PCCount") == 1)
{
object oWP = GetFirstObjectInArea();
while (oWP != OBJECT_INVALID)
{
string sTag = GetTag(oWP);
if (sTag == "ACR_SPAWN_WP")
{ACR_SetIsSpawnPointEnabled(oWP, 1, 1);
}
object oWP = GetNextObjectInArea();
}
}

and the reverse if the counter shows the number of PCs to be 0 OnExit. This does absolutely nothing useful. Heh.
I've looked at the code in aca_spawntoggle, the spawn disabling wand AL made, but I'm a bit leery of it because that doesn't seem to work if you have more than one spawn point in an area. Any pointers on how to go about this gratefully received.

2) There is the possibility that a PC's location will be saved inside the encounter area by the main ACR scripts, meaning that you could log on back in the encounter area. This is not ideal. Is it possible to disable location logging within an area?

3) Dead PCs aren't a problem for the system in that they move to the morgue. Bleeding PCs, however, will prevent any further encounters happening until they die or recover and exit. Should we have another pseudo-heartbeat running that moves PCs with negative hit points back to the travel area if there are no other "conscious" PCs in the area?

4) Killed PCs will drop their goods in the encounter area. Obviously this presents the possibility of considerable amounts of loot stacking up for later PCs to come across. Should it be deleted (I don't know the Standard for PC loot drops) or moved back to the travel area with the corpse?

I appreciate that it's difficult to have an opinion on this without seeing it working, but I'd like to have a version as close to finished as possible before putting it up for testing. Catch 22.

Many thanks,
Teric

[ç i p h é r]

It's not currently possible to "deactivate" location saves, though we could prevent the system from saving locations on Travel Maps if an area could be specifically tagged as one. Question though is, why wouldn't you want a PCs location on a travel area saved?

When PCs are killed, all their inventories are dropped into a corpse object, which acts as a persistent container until the corpse inventory is cleared out. Deleting the inventory would mean the PC would lose those items forever, even if resurrected, so I would not recommend doing this, if I understood your question.

[Mayhem]

The issue there I assume is that a particular clearing etc for encounters on the travel map is supposed to be a "generic clearing" that might occur anywhere on the route, not a specific one - so it is not appropriate for a body to be persistantly stored there as next time somebody comes to that area, it is probably supposed to be representing a different area.

Not storing it accurately represents the difficulty of finding a body of somebody that wandered alone into the wildreness.

Such bodies should not be erased, though, but stored elsewhere - as it should be possible for specific "missing persons" to be found using magic or tracking skills.

[Teric neDhalir]

Cipher, it's not the travel area that needs to have location saving disabled it's the encounter area (i.e. a separate area you get moved to if you trigger an encounter). Same difference tho' - if we can prevent locations being saved in certain areas that would be great.

And I'll have to put stiffs back where I found 'em

[AcadiusLost]

Persistent corpses, like other p-storage, can be "despawned" rather than destroyed, if you want the contents to return when you create a new one with the same settings. It's just a matter of setting the local variable on the corpse that tells it not to drop inventory when "killed", before the DestroyObject() call goes out. So long as a valid ACR_DTH_LOCATION exists in the database for the corpse, a module reset will spawn up a new one, which will be stocked according to the saved content list.

The actual spawning of PC corpses is a bit tricky, since they have to be customized from generic placeables- right now we do it for all corpses from the RestoreCorpsesOnModuleLoad() function in acr_death_i, it wouldn't be too hard to adapt a custom version of this to work on-demand for corpse restoration- in fact, it might serve a dual purpose in assisting tech rezes of decayed corpses (something like the "Death Chest" implementation of NWN1-ALFA). Just thinking aloud there, though.

Another level of information will have to be saved persistently, though, to track where the encounter area "occurred", so one can decide weather or not to spawn the corpse during subsequent "encounter area activations".

With regards to location saves, we could easily enough add some logic to the location save functions (or the events that call them) that handle matters differently for PCs in an encounter area. Currently Location saves, if I recall correctly, update OnEnter of a new area, and on a long pseudoheartbeat (as well as whenever a PC rests, or uses PC tools Save PC or Save Location buttons).

I've recommended elsewhere that we add a location cache to the PC as a local Location (SetLocalLocation, :p) to help the logout/server reset location restore have better fidelity. If we just wanted to store the PC's location as the point on the Travel Map from which he or she entered the encounter area, we could just change the cache to update as an early part of the AT script into the travel map area, and a local int on the PC could be set to acknowledge their "encounter" status.

Some of the finer points of this may need to reflect what changes we may make with Persistent Location restoration (ie, what conditions cause the persistent DB location to override the automatic module memory). If we leave that more or less as-is (DB location only used when last location is invalid ie: after a server crash/reset), all we'd need to do is save location before entering the encounter area, and skip updates while inside it.

Thanks again for the work you're putting in on the travel map system.

[darrenhfx]

Yes indeed, it's much appreciated.