Seamless ATs

[Fionn]

No, on a failed spot check DC 5 we might allow ATing into a spawn. My issue is a CR1 mouse preventing me from getting into town. On a success DC 15, I should be able to choose to AT into the CR 1 spawn. On a success DC 10, I should be able to choose to AT into an unknown spawn.

[ç i p h é r]

If transitioning is going to be conditional, then I think player's should have the ability to set their transition preferences. Not only could spawn blocking be a nuisance, but it could be fatal when a PC is attempting to flee from something. Ironically, fatalities are what we are trying to minimize. I think we should at least offer these config options:

• Do not transition with spawns nearby
• Always transition
• Ask me

The last option would have to trigger a dialogue, which could report the creatures the player has spotted, and then let the player decide the course of action. Possible options:

• transition
• transition and do x (attack? cast spell?)
• withdraw

Alternatively, limit this feature when a player is in an active stealth or search mode. That would imply that they are "scouting" and thus the extra feedback is warranted. By limiting this to a specific action mode, a transition could never interefere with player movement when it's least desirable - running away.

[Ronan]

I was just thinking the PC could walk outside of the AT-trigger if he spots a spawn on the other side. Seems simple enough, and stopping ATs if a player leaves the trigger is something I'd wanted to do anyways (and its easy).

Not sure on the best way to handle hostiles at the moment. The only thing I have to add is to not bother with anything too complex. We may be best simply making the PC cutscene invis and uncommandable for a brief period of time.

[Creslyn]

Might be as simple as paralyzing both the PC(s) and the monsters for a short period after AT'ing, so players get a short time to decide what to do about it.

[AcadiusLost]

What my system does so far: (in a NWN1 background, all I had to work with while away)

1. References a local int for ACR_SA_XMAX, as well as a similar one for y maximum, stored on the area. If these are missing, it tries to deduce the area size (assuming a square area) based on the position of the AT triggers in the area.

2. Predicts a target area tag to send the AT'ing PC to, based on the direction and the tag of the current area. uses a pXXXnYYYpZZZ convention, with p/n for positive/negative coordinates. A constant is referenced to determine how "big" an area should be on the grid scale. If the proper predicted target area cannot be found, an error is returned and the PC is not AT'ed.

3. Checks the destination location for a plausible return AT. Since the location of a trigger appears to be the location of it's initial point while laying the trigger bounds, it checks for any triggers with the standard tag ("SeamlessAT") within a radius of the calculated destination, equal to the xMax of the target area. If no AT with such tag is in-range, it returns an error and does not AT the PC.

4. Checks the destination location for creatures with GetIsFriendly FALSE within a 25.0 radius. If one is detected, the PC is warned there is something ahead. A spot check is rolled automatically- DC20 passes the GetName() for the nearest hostile as well as the names of other creatures in a 25.0 radius from it. A failed check gives a generic message about something up ahead. The AT attempt is halted after passing this information, but can be forced by clicking on the AT, or leaving the AT and trying again from a different point, further from the detected hazard.

5. If/when the PC does AT, a vfx is triggered at the intended destination point, before the PC goes to the loading screen (unless the AT'ing PC is in stealth mode). This should make accidental cross-Ating a thing of the past, as this should forewarn of an approach. The PC's party is also informed of the direction of the AT, which should help in allowing parties to AT together despite ambiguous corner diagonnal ATs and such.

6. Upon entering the new screen, the PC is rendered ethereal for a few seconds. This gives a chance to get one's bearings or turn back, and should be dispelled automatically by any hostile action. They will arrive 0.5 into the area at the appropriate edge, but will not trigger the AT back, unless they purposefully click on the AT. Leaving the AT will reset the triggers, allowing it to fire again just from approach back towards the same edge again.


This code needs some cloaning up and commenting, as well as a good port to and testing in NWN2 conditions. I'll do what I can of that before bundling it up to put wherever you people put these things for public consumption. The Xmax prediction thing can still be a bit screwy, so I'd recommend any builders to define their X and Y max INTs in any gridded seamless AT areas. Also, any recommendations of a suitably noticable yet non-immursion-breaking nwn2 VFX for the OOC notification would be welcome.

[ç i p h é r]

Is the PC commandable (by player) or targettable (by hostiles) during the brief "acclimation" period?

[AcadiusLost]

Yes, and yes. Commandable and targetable, currently. The ethereal effect is applied for a brief period, which should give a few seconds to exit and re-enter the AT, or to click on the trigger to force an AT back the way they came if so desired. It's my understanding that the ethereal effect hardcode drops automatically on offensive action, so we shouldn't have to worry about PCs getting any immortal swings in against an AT-camped foe. At least, that's what the nwn1-lexicon suggests. It would, of course, bear some testing to confirm, ideally in a NWN2 environment.

[ç i p h é r]

I think we need to make sure a player is not targettable and cannot take any action to avoid the possibility of exploits at ATs. I'd be more comfortable with applying a cutscene ghost + invis vfx and making the player uncommandable. Put them into cutscene mode basically. They can click on the transition once the effects drop, if they don't like what they see, and since they are invisible and connot be targetted, they don't have to worry about anyone or anything reacting before they do.

That's my opinion at least. Maybe play testing will show it's a precaution that's not needed.

[indio]

Acadius, if you want me to test this system, let me know.

[AcadiusLost]

On friday I ported this code to NWN2, had to rejigger some bits to handle the "gutters" of unwalkable area that NWN2 adds to all exteriors, but I think the basics are working now. It's certainly going to need at least a bit of tweaking.

#1: in NWN2, you can't see where the edges of an area are: generally, you don't know them until your PC stops in midstride (or tries to AT, if you have these seamless triggers laid down). This may mean a fair number of "accidental" ATs, which can be frustrating for folks, especially if we continue to have issues like the chat log clearing with each AT. It might be nice to allow "cancelling" an AT by walking back out of the trigger quickly, though I'd have to think about how to add that to my current code.

#2: As it stands, a PC will always be prevented from ATing into a hostile NPC / creature: the only thing the spot check determines is whether the PC gets the name(s) of the creatures on the other side of the AT. (using 25.0 as the radius for this, for now) Under nwn1, it allowed clicking on the AT (on the ground where the trigger is/was) to force the AT anyway: so far this doesn't seem to work in NWN2. This leaves us with a choice of warning them but relying on them to leave the AT quickly to avoid (using the above system), or trying to work out a different "confirmation" system. Also, thoughts on the DC 5 check prerequisite for protection against walking into camped spawns? I'd just as soon leave it out, but I can include it if there is widespread support for it.

#3: Quirks of back-ATing: as Ronan recommended, I've got the scripts jumping a PC 0.5 into the usable area of the screen, which is inside the return AT's bounds in almost all cases. As such, the PC has to actually leave the AT and re-enter it to backtrack: this can be nontrivial if the ATs are painted too wide, it may pose a frustration to some users. Furthermore, if you've got overlapping seamless ATs, or slight gaps between the AT and the edge of the walkable area, the PC may accidentally back-AT at them while trying to leave the AT (due to a momentary exit and re-entry to a seamless AT trigger area).

#4: I've got a few other things I'd like to fix: like reapplying the leading zeroes to the composed tags of the areas (necessary for < 3 digit coordinates), and adding handling for NPCs/creatures ATing (currently they're treated just like PCs, we may want to treat them differently).

On the subject of coordinates: I've based my system on a p/n (positive/negative) world-coordinate system of this format:
pXXXpYYYpZZZ for the tags of the area: "n" is used in place of "p" for negative values, the Z coordinate is just inherited from the area a PC is departing. I also define a constant int for the "scale" of the areas, which should allow builders to decide if their areas should be 1, 5, 10, 20, etc. "wide" by this scale (eg, should p250 be next to p255, or p251?). Will three digits be sufficient for this? With the full positive and negative scale, I expect it's workable, but I figured I'd check, changes are easiest made while I'm puttering around with the tag composing function. At a scale of 5 per area, we'd be looking at a range of 200 areas in each direction from our cardinal/meridian point (elminster's tower was one suggestion). Builders who wanted more detail could drop to a 2 or 1 scale, but does it sound reasonable?

Any thoughts or input on the above would be welcome.

[Zelknolf]

#1: in NWN2, you can't see where the edges of an area are: generally, you don't know them until your PC stops in midstride (or tries to AT, if you have these seamless triggers laid down). This may mean a fair number of "accidental" ATs, which can be frustrating for folks, especially if we continue to have issues like the chat log clearing with each AT. It might be nice to allow "cancelling" an AT by walking back out of the trigger quickly, though I'd have to think about how to add that to my current code.

Have your main function set a local integer on the PC as 1, then have a
DelayCommand(2.0f, FunctionWithATCode);
after it. Have the trigger's OnExit set that local int to 0, and start the function with the AT code in it with a
if(!(GetLocalInt...)) return;
and finish that function with setting the local int to 0.

[AcadiusLost]

It gets a bit fiddly, as actually ATing a PC means they trigger the OnExit from the original AT trigger, so you also have to distinguish script-wise between leaving an AT manually (to abort) from the departing of the trigger during the "AT" itself. You've got the same deal with the OnEnter: is the PC landing in the trigger from another screen, or has he/she just entered it normally?

Add another level of complication with whether or not the PC has been warned (or should be warned) about a spawn/hostile NPC on the other side of the AT, and you'll have the scenario. We want to use exiting an AT manually as an impetus to clear the AT-related variables, but also need to account for the "extra" onExit firing that comes from "leaving" the initial trigger.

I'll see if I can integrate it smoothly this weekend, if I can make time for it.

[AcadiusLost]

Allright, had some time to play with these this weekend, seem to be working passably. Next stage is probably getting it out there for MP testing on one or more of our beta servers: I can't be in the 2 places at once necessary to see if the VFX are firing correctly, nor to find out if it's reporting to party members as it should be.

The way I've got it working now, stepping on a working seamless AT notifies you of the direction you're going to be moved. Then it starts a 3-second timer, the last 2 seconds of which are supposed to be with a temporary ethereal effect to protect PCs trying to flee across the AT.

If the PC leaves the AT during this time, nothing will come of it: so you can backtrack within 3 seconds if you don't really want to AT.

If there is a hostile within 25.0 of your predicted target in the next area, the system rolls a DC20 spot check for you. Success means you are given the GetNames of the hostile and any others within the 25' radius, failure gives an ambiguous "think you see something moving ahead". The timer is extended to 6 seconds, to give greater chance to abort.

The other functions, checking for return ATs and such, seem to be working so far as well.

Currently, the destination warning VFX is set to fire at the /start/ of this whole process, just before the 3-second counter, meaning it will play anyway even if the PC aborts the AT. Also means the warning that something is ATing towards you will come 3 to 6 +loading time seconds early. Better to link this to the actual MovePC function? Would avoid the "false alarms" that way, and be a shorter notice (just the AT'er's loading time). Coming to think of it, does sound better that way, or a pair of potentially cross ATing PCs could be doing a dance of second-guessing trying not to cross AT, which is just about opposite of what we were going for.

So, I'll make that fix, then see about getting an erf with these in a Module Trigger onto that FTP thing.

[AcadiusLost]

Allright, uploaded these for testing on any of our Betas that wish to play with it. Fixed an issue with not being able to flee across ATs while in combat (added a ClearAllActions), and moved some of the tweak-worthy variables out into constants in the include. As of now, it appears the ethereal effect isn't taking like it's supposed to, for whatever reason.

So, builders can download and import this erf, it should add a module trigger blueprint for "Seamless AT", as well as the following scripts:
acr_areatrans.nss
acr_areatrans_i.nss
act_areatransoff.nss

The include has the variables for AT delay, warning radius, etc. Try them on default unless you want to fine-tune.

You'll need to tag your seamless AT exteriors as pXXXpYYYpZZZ, where p/n denotes positive/negative coordinates, and each area is "5" in size.

so, an example grid:

p050n045p000 p045n045p000 p040n045p000

p050n050p000 p045n050p000 p040n050p000

p050n055p000 p045n055p000 p040n055p000

and so on. Should work for most standard-size, square exterior areas. Just draw the SeamlessATs along the edges of the walkable area (try not to leave a gap at the edge) and you should be ready to go.

the ERF is here: ftp://alfatech:moonblade@ftp.alandfaraw ... sAT_v1.erf

[ç i p h é r]

AL, can you commit your source code to our repository?