A Land Far Away

During a discussion of the Seamless ATs, and dynamics of creatures/mobs chasing PCs from area to area, this came up:

indio wrote:AL, will your code adapt to regular cave door transitions?

My initial thoughts on the matter are quoted here- what do the rest of you think of the idea?

AcadiusLost wrote:It won't work for cave ATs at all- it needs to be at the edge of an exterior-type area currently.

If it's desired, I can pluck out the useful bits of the code to make a more generalized AT system, though there are some potential problems, namely that you can't "see" these ATs on a mouseover like you could with old NWN1 blue ATs- so they tend to take PCs by suprise.

With regard to cave entrances: those still use "door" type ATs, right? Currently we have the ACR doing prespawning for destination areas using those, though we don't have the delay/protection/spotccheck-hostile warning controls set up for them like seamless ATs have. It's certainly something doable though, and potentially in fairly short order. There are quite a few cases to consider though, as it could be trigger to door, door to waypoint, or door to door- the good news is the destination calculation is a lot simpler than for the seamless ATs.

I think the thought was that with door/waypoint ATs, the builder has a lot more control of where the PC will end up, compared to seamless. Would you still want the 3-second "abort" delay whenever you try to enter a building? Do we want to deny door or trigger-based ATs that have no detectable return ATs, as we do with the Seamless system? Should we be playing a VFX on the other side of the door like we do with seamless? All things we'd have to consider in adapting the code. I'll crosspost this to the ACR forum, as the discussion is better held there, to leave your Beta forum focused on bug squashing, heh.

[/quote]

Well, the risk of exploit isn't great enough to justify spending time on it imo. I'd just stick with seamless ATs.

If you can extract the VFX behavior from the SAT code, then I would say yes, this is a good addition to transitions overall. I think we had a similar conversatin about prespawning mobs as well.

One note though. Is the VFX behavior applied irrespective of what is in/on/near the transition? If the player cannot see any hostiles, I would hope that the system be smart enough to not interfere with gameplay. It's supposed to be a preventative measure for a specific situation after all.

Currently, I believe VFX are played for NPCs as well as PCs, with a rather primitive control to account for sneaks- I'm not familiar enough with the perception/seen/heard/ms/hide mechanics to do better offhand. It would be easy enough to revisit later- for the most part, it's there to keep PCs from accidentally cross-ATing without realizing they've just walked right past each other.

Door type transitions, at least traditional ones, should open before a PC emerges, so there is some warning (though since players can't close AT doors manually currently, I suppose there is still reason to consider adding a transition VFX).

In terms of mobs following PCs through ATs- we'll have to see how it works in Beta. If they're consistently not doing it when they should, we can try to look into adding something to their AT (get location of where they last saw the PC, assigncommand to move there, should put them in the AT as well, though we may have to also search for doors in a small radius and assigncommand to use them)- I'd rather not dig too far into AI scripting if we can help it, it's an area we'd likely be best off waiting for (properly doumented) vault content, rather than struggling with the poorly documented OE systems.

I've already hooked prespawning into the acr_area_i.nss a while back- if I've neglected to upload that version, I'll get to it tonight. We could go halfway with the other area transitions- remove the 3-second base delay (as presumably the PC knows what they just clicked on, unlike a seamless AT they've entered), but /add/ a 3-second delay and warning if we've got the hostiles right by the transition target location, with the same basic code we use for the seamless ATs. I could also plug in the checks for a return AT- though there may be some cases in which builders wouldn't want this, I suppose.