Seamless ATs

AcadiusLost · Post by **AcadiusLost** » Sat Dec 23, 2006 5:58 pm

Been putting a bit of my vacation down-time into scriping a universal seamless AT system. The problem I'm having now is in measuring the size of areas, so as to gauge the northern and eastern edges.

The lexicon suggested that you can check validity of a location by creating it with Location(), then seeing if you can GetAreaFromLocation to be valid. Tried that, testing just beyond the range for each of the standard area sizes. However, it's still getting an area back even when I create a location at 319/0.5/0.0, in a 16x16 area, which should end at 160.

Other ideas?

Fionn · Post by **Fionn** » Sat Dec 23, 2006 6:44 pm

Try to create an object at that area - it's possible it ends at 1600 now.

AcadiusLost · Post by **AcadiusLost** » Sat Dec 23, 2006 6:49 pm

Working this out using nwn1, since I'm away from my desktop on vacation, so no switch to 1600 yet. might try the creation, but don't want to do that every AT for sure.

Ronan · Post by **Ronan** » Sat Dec 23, 2006 7:37 pm

We may want to actually calculate and cache area size OnLoad, as this is something other scripts may use. NWN2 provides GetFirstArea() and GetNextArea() functions, so all the areas could be looped through and have their area sizes saved to local vars ACR_ASZ_X and ACR_ASZ_Y (or something) on the area objects.

I told AL in a PM he could try checking the resulting location of these created objects. But worst-case, we can just assume a constant area size.

BTW, were you deviating frolm Hialmar's coordinate tagging scheme at all?

AcadiusLost · Post by **AcadiusLost** » Sat Dec 23, 2006 7:49 pm

The tag-prediction method I've used assumes pXXXpYYY from the left, and just appends the rest from the area you're coming from. Measuring and caching onload sounds like a good idea- my current algorithm tests for most common sizes first 32x32, 16x16 etc

Ronan · Post by **Ronan** » Sat Dec 23, 2006 7:54 pm

Alright, we'll need a grid ID somewhere in that tag as well. If you decide on a final tagging scheme, let me know or edit the wiki article or something, because some builders want it.

Though I wouldn't spend a lot of time on measuring area sizes, I just don't think allowing different sized areas is all that critical.

HEEGZ · Post by **HEEGZ** » Sat Dec 23, 2006 8:58 pm

Hmmm, I didn't realize our NWN2 servers were going with a grid system like in NWN1... Guess I'll have to have a look at the proposals again. AL, I think quite a few teams are looking at heavy use of 24x24 so might keep that in mind.

Ronan · Post by **Ronan** » Sat Dec 23, 2006 9:09 pm

HEEGZ wrote:Hmmm, I didn't realize our NWN2 servers were going with a grid system like in NWN1...

I know WD and MD are, at the least. I think its a good thing to do in case the area limit problem lessens. There really isn't a great reason not to in a lot of cases. Just becaues your areas are positioned on a grid doesn't mean you have to fill the grid in or whatever.

HEEGZ · Post by **HEEGZ** » Sat Dec 23, 2006 9:18 pm

Ah yes, I hadn't thought of the urban locations. I was thinking the wilderness areas.

AcadiusLost · Post by **AcadiusLost** » Mon Dec 25, 2006 12:40 pm

Added 24x24 to my list of presets the system tests for, also accomodated combinations of them (32x24, 8x24, etc).

Unfortunately, creating a waypoint outside the boundries of an area, at least in NWN1, seems to work fine... not only that, but when I test location of the newly created waypoint against it's intended (out of bounds) location, it doesn't appear that it's moved into proper bounds or anything.

Could try making a placable or a creature instead, I guess.

Ronan · Post by **Ronan** » Mon Dec 25, 2006 4:42 pm

AcadiusLost wrote:Could try making a placable or a creature instead, I guess.

I really just wouldn't worry about it now. We may get the GetAreaSize() functions back in the future anyways. You could just take the area size from the CreateGrid() call.

ç i p h é r · Post by **ç i p h é r** » Wed Dec 27, 2006 8:53 pm

What about a variable in acr_settings_i that allows each server team to define their own grid sizes? That way, you predict grid intervals based on local server settings and avoid having to test every combination possible or having to achieve a consensus among server teams where needs will vary.

I don't think a seamless AT system makes much sense for servers with completely random area sizes as edges simply won't line up. Those builders have made a conscience design decision and surely understand that ATing will have to be custom fitted to each area as a result - they may intend to rely exclusively on the world map for all we know (much like the SP campaign).

AcadiusLost · Post by **AcadiusLost** » Sat Dec 30, 2006 5:17 pm

Got things more or less sussed for basic ATing, put in a test for creatures near the AT target- any thoughts on what radius to use? 10.0 still seems very close, maybe we should aim for just beyond perception range?

Also, currently I've got it failing the AT, and telling the PC there is a spawn too near the AT point. Any thoughts on more elegant solutions? It's not a lot of meta info to pass, really.

Fionn · Post by **Fionn** » Sat Dec 30, 2006 6:16 pm

Well, I'd state something akin to "You see something ahead and draw back". Also, if possible, we should allow the the change to get the mob type (and perhaps name) on a good Spot roll. There should be some method of forcing the AT though - perhaps a "kill all actions & speakstring" at 25, and a "just AT" at 10

AcadiusLost · Post by **AcadiusLost** » Mon Jan 01, 2007 1:39 pm

Fionn wrote: There should be some method of forcing the AT though - perhaps a "kill all actions & speakstring" at 25, and a "just AT" at 10

Not sure I follow entirely on this bit- do you mean that, on a failed spot check, DC10, we should let the PC AT into a spawn? While I agree in principle, it could lead to the rather OOC and deadly arrangement of a party travelling together, with the low-spot PCs ATing into danger, while the high-spot PCs are blocked and have to "go around".

It gets rather more complicated if we want to allow PCs to AT into mobs on purpose, we'll need to track a local int on whether they've been warned yet or not. Kind of getting overcomplex IMHO. I can have a play with it, though.

Interested in other thoughts along these lines as well- added features would be gathering approximate number of creatures in a radius, etc- gets more complicated on the code end, but not un-do-able.

Keep in mind as well, Ronan's spawn system will likely handle things such that dangers on an AT shouldn't be nearly as common.

As an aside, any thoughts on a good criteria for disregarding creatures near an AT? Reputation check to PC?