Cookies Disclaimer

I agree Our site saves small pieces of text information (cookies) on your device in order to authenticate logins, deliver better content and provide statistical analysis. You can adjust your browser settings to prevent our site from using cookies, but doing so will prevent some aspects of the site from functioning properly.

Pathfinder Online will be ending operations on November 28, 2021. For more details please visit our FAQ.

All posts created by Bob

The message you're seeing is more of a generic statement about what's possible in a High Security hex than a policy statement about Thornkeep. That said, the main reason we added a policy forbidding PvP in Thornkeep was that we didn't yet have a good way of protecting new players and it was safer to simply say all PvP is forbidden there than to try to figure out whether a potential target was a new player or a veteran. With the new per-hex Security settings, I'm open to allowing sanctioned combat in and around Thornkeep. Does anyone have any particular concerns with lifting that restriction now that players can only be attacked in High Security areas if they're involved in a feud or otherwise got themselves flagged as a sanctioned target?
I made a pass through the public spreadsheets to update everything through EE 12. Along the way, I made a few changes to the spreadsheet's format, hopefully they won't cause too many problems for those of you using automated tools to parse the data.

  • On the Weapons (Standard) and Weapons (Caster) tabs, added an apostrophe to the title for the quality column so it can start with a + sign and not be treated as an error. The formula for those column titles is now technically '+0 Quality which just shows up as +0 Quality.
  • Added a new tab for Recipes (Aeon Stones).
  • I added a tab a while ago for the Codex recipes, and for EE 12 added the T2 and T3 variant recipes. I noticed the original T1 Codex recipes aren't up on goblinary, so I'm not sure everyone's aware those recipes are on a different tab.
  • Added Effect +0 and Prerequisites columns to the Misc Gear tab to better handle Aeon Stones.
  • Renamed Release column in Bulk Resources tab to Hex Type.
One oddity that still occurs is targeting, but not attacking, a mob will often see them select you once your party pulls even before you attack. This seems independent of where you are positioned (as clearly moving to one side to target a mob better moves you closer to that mob) as it can occur even if they are behind other mobs.

Is this a genuine phenomena or just Edam trying to find a pattern that is not really there? No idea to be honest. It is hard to see how the mobs can"know" you have them tab-targeted given the current description of aggro mechanics but it certainly seems that way.

We probably could take into account who's targeting who, and in some ways it wouldn't be all that weird. After all, that would just mean that each mob has a tendency to target whoever's looking at them funny. However, the AI doesn't actually take that data into account, so it's probably just the "make sure someone targets Edam" code kicking in.
Stilachio Thrax
As one of the people Mistwalker was grouped with, this wasn't an issue of Mist nuking multiple enemies while the remaining people were low T2 plinking away. This was a geared out T3 group that knows what it is doing, mainly single target damage with only a smattering of AOE.

Another thing that can throw things off is that we're currently only taking into account straight damage, not buffs or debuffs, so a character doing straight-up damage might pull away more mobs. But generally speaking the team hate list is only partially shared, so a mob that's smacking away at one character and doing some damage to that character should stick to targeting that character as long as the character is in range and no other character comes along and does a huge amount of damage to it. One non-obvious exception to that would be if the only reason that mob is attacking the current character in the first place is that the character was in-range while its actual intended target is out-of-range. In those cases, the mob might switch targets either just to see if it can manage to get closer to its intended target or if the intended target comes within range.

There are a lot of subtleties to the system, and we'll keep fiddling with it as reports come in.
Seneschals are an interesting case because their refining capability was a later add-on to their original purpose of lowering upkeep costs. At a quick glance, allowing it to qualify a character for holdout weapon could be reasonable, but I've filed a bug to take a closer look when I have a chance.
Nice catch, bug filed.
Hobson Fiffledown
Please consider changing one of the three(?) tutorial monster hexes to low security. If PFO is still being billed as an open-world PvP game, there really should be an open PvP hex included in the tutorial areas. I don't really think that needs to be argued any further. It would also give a nice non-political area for shenanigans, or tourneys and games.
"But, Hobson, what about the packs of spooky murderhobos?"

1. Opt-in PvP
2. One of three available hexes.
3. There is no shortage of players who would run a character from TK to chase off some really big bads.
(but, c'mon, I'd never leave this hex if it happened and even I wouldn't kill everyone…all the time…definitely not the newbies)

Of the 3 monster hexes closest to Thornkeep, two are running the tutorial escalation and are set to High Security. Both are currently next to Badlands hexes, which are the same distance from Thornkeep and are currently set to Low Security, so there is some Low Security stuff in the immediate vicinity.

My general feeling was that I didn't want to have any of the places that new players are being advised to go to as part of the initial tutorial quests be anything but High Security. There's one exception that I only realized in retrospect, where some of the targeted mobs are available in one of those Badlands hexes, but new players are likely to kill all they need long before wandering that far away. Still, it's not ideal, and I'll probably revisit that at some point. As we evaluate things, I may also want to extend the safe area out a tiny bit further from Thornkeep, perhaps at least on the roads, but we'll see how things play out.

Longer-term, it could be useful to create a PvP tutorial that sends players to the nearest Medium/Low Security hexes to learn a little about the risks involved. That would involve at least making sure such hexes are reasonably nearby, but would also be very explicit about what it's getting new players into. I'll have to look into that when I have a chance.
Hey Bob, it would be really helpful if the "feat" tab/table indicated not just your current level, based on support, but indicated the highest rank, support level and modified feat level.

Or at least something either on the character sheet or the feat tab to indicate what the support level is.

If that is not present, a few folks will likely become frustrated trying to figure out why their feats aren't as high as they should be, or why they can no longer make something, etc…

The tooltip for each feat does show current rank, supported rank and modified rank, but admittedly before bringing up the tooltip we're just showing the modified rank and no hint that it's being modified. I've added a feature request to at least hint at the fact that the rank is being modified due to lack of support so that players will be more likely to bring up the more detailed tooltip.
Duffy Swiftshadow
After playing with the settings I think I just realized there's no way to block settlement-less players or companies that doesn't also block any settlement connected players not on any of the other lists, both cases get lumped into 'Unaffiliated'. This creates an awkward hole that can be used to get around blacklists, mainly useful for circumventing bank and AH restrictions. This can be accomplished either by dropping company temporarily or using 0 XP alts.

Yes, that is definitely a risk taken if you open things up to unaffiliated characters. You can get around it if you use your blacklist as a whitelist instead, blocking access for all unaffiliated characters and then granting access to all (or virtually all) settlements. You can then just remove any settlement from your whitelist that continues to allow members that you would have blacklisted.

Longer-term, I've added a feature request to specifically add a whitelist so that you won't have to give up your blacklist functionality in order to do something along these lines.
I may be mistaken, but I was under the impression that the AI "hate list" would only kick in when they couldn't hurt their opponent, or weren't taking damage.

There are a few different points where a mob might decide to switch targets mid-combat even though the current target is still around. If a different character starts doing a lot of damage to that mob, then that character could rise to the top of that mob's personal hate list (particularly if that mob isn't doing a lot of damage to its current target), and the mob would switch targets. That part has always worked that way, but would probably only really kick in when the current target was running away and staying just out of the mob's range, while someone else was doing quite a bit of damage to that mob.

Something new is that mobs also have a shared team hate list, which is added to whenever anyone on the team does damage or takes damage. A certain percentage of that hate is shared back out to each team member's personal hate list. This generally keeps each mob's personal hate list a bit more full and evened out, though they'll still usually focus on whoever they're personally damaging or being damaged by. However, it does mean that if one character does a lot of damage to one of the mobs on a team, or a reasonable amount of damage to a lot of the mobs, while all the other nearby characters are dealing/taking minimal damage, then that character could rise to the top of many of those personal hate lists, resulting in many of the mobs switching to target that character. This can also happen if one or more of the mobs do a lot of damage to a single character while all the other characters are minimally engaged. To keep the mobs spread out on their initial targets, those targets need to engage in the combat so that they're taking and receiving damage. If they're busy trying to pull their attackers out to leashing range, those mobs will likely switch to a more viable/threatening target pretty quickly.

Also, we always had a system in where a mob would check every few seconds to see if there's a different character on their hate list in range while their current target is out of range. If so, they're supposed to go ahead and fire off a single attack on that in-range character. If that attack does a lot of damage, that could move the new target to the top of that mob's personal hate list, resulting in that mob permanently switching targets. If only a little damage is done, then depending on the exact timing of those checks, the mob might return to chasing after its original target. There was a bug in that code that made it only work for certain attacks by certain mobs, but that's now been fixed and works for all attacks by all mobs. The end result of that is that if one character rushes into an encounter while everyone else hangs back to take on the mobs as they spread out, there's a good chance that any of the mobs who find that brave soul in range will go ahead and attack that character at least once before spreading out. Combine that with the team hate list and it's quite possible that the character who rushed into battle could quickly be at the top of all the personal hate lists. Avoiding this again requires that everyone engage quickly.

And that on bounce, that they would spread out an attack all PCs in the area.

We're not technically spreading the targeting out when mobs bounce, we're just avoiding the previous code that practically guaranteed the mobs would all bounce onto the same target. What actually happens is that each mob copies the team hate list, picks a random character from that list, and then elevates that character to the top of its personal hate list. Because it's random, the leashed mobs could randomly just happen to all target the same character. Also, if many of the characters have managed to fall off the team hate list (particularly likely if they were running outside leash range), then there are less characters hated by the team to choose from. A character who just caused a mob to leash needs to quickly re-engage, taking or receiving damage, to get back on the team hate list.