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

Bob
Maxen
I definitely understand and appreciate this, but swapping out attack/utility feats is a huge inconvenience under the current GUI. Fast forward to the time when you can consider this (because I’m sure it’s no small task):

Allow users to create multiple builds for characters that can be loaded. On the fly would be awesome, as in “this suite of attacks and utilities are ineffective against this player or mob so I’m switching tactics.” Just because they are not slotted doesn’t mean they shouldn’t be at my disposal. After all, I spent XP and coin to acquire them. I’m not talking about swapping role features or armor or weapons. Just attacks and utilities associated with the equipment I currently have slotted.

If there are some abuse concerns, perhaps you have to come out of combat to make the switch. Or extreme case, the build is selected on the load screen. Just something to consider.

We've talked about this kind of thing multiple times and definitely still want to implement it eventually, and we'd be pretty likely to use an out-of-combat restriction. After all, you can do most of these things between combat now, it just requires a lot of manual steps. You are correct, however, that something like this wouldn't be a small task, though in many ways it just automates things you can already do, so at least there's already plenty of code we could hook into.
Bob
Iram Thelbane
Bob, is it easy to increase the slot number of utilities and items? Because add one more of each will be a great improvement.
It will allow us to use more than two utilities and items in the same time, that is usefull. Plus adding one more item slot can allow us to use one more item that can have a situational usage. I think that this kind of improvement could develop item trading…

(It also be usefull to increase expendable and attack slots number… I think that it's a lower priority, but it can be great too!)

Adding more slots isn't incredibly difficult, but it does require reworking the art and making some code changes, so it's not trivial either. There are also issues with hotkeys for the slots. For example, the current 6 attacks, 2 utilities, 2 items system lines up well with the keys 1-6, 7-8 and 9-0. We'd have to rethink that a bit if we added more slots.

The bigger issue is just one of balance, where part of the game's design is to balance players out by limiting how many options they can bring into one combat. No matter how many weapons you can use, you can only bring 2 into battle. No matter how many attacks you've learned for a weapon, you have to choose 6 for use in a given battle. We have to be pretty careful when adding slots not to throw that balance out of whack.

That said, we have had multiple discussions about making it easier to use those slots. In particular, we've tossed around the idea of treating the item slots more like ammunition containers, with one letting you carry a larger selection of tokens, and the other letting you carry a larger selection of potions/grenades/etc. That could make it more compelling to carry a larger amount of crafted consumables on each outing, and could also provide a more specific role to tokens. That again isn't trivial, but we'd still be restricting you to the same number of slots in any given battle, so it keeps the main UI art in place, doesn't mess with hotkeys, and still restricts your choices going into each battle. It's more about making those slots easier to use in interesting ways over the course of a complete session, rather than making them more flexible during a single combat.
Bob
Trippic
Bob, it appears from your answer that a keep + X is not necessary in order to set settlement level at Y. Therefore since Keep only trains seneschal, and it is at this point (unless you change the requirement from Social Points to something we can actually obtain) impossible to effectively get above level 13 in seneschal (a major impediment to building higher level buildings) there is no purpose to building a keep up past level 2. Is that correct or do you intend to alter any of the parts of my analysis that would change the analysis?

You can set your Settlement Level all the way up to 20 regardless of how upgraded your Keep is, but you still can't upgrade any of your other structures higher than your Keep. So if you want a +3/4/5 Temple, you'll need a +3/4/5 Keep.

That said, we do need to get the Seneschal issues fixed at some point. We've tossed around some ideas for other Social Achievements, but most (if not all) will require some code work.
Bob
Testing on Zog is going well, so we plan to deploy EE 14.3 to Live as previously scheduled during Daily Maintenance (9-10 AM Pacific) on Wednesday, January 10. If anyone would like to take a look at the build and needs test server access, just send email to customer.support@goblinworks.com and I'll get you set up. If you find any bugs, send email to the same address, file a support ticket in-game, or post a message here.
Bob
Giorgio
Now that the holiday escalation event is over, when can we start talking about EE15, a revision to the Road Map, and lots of controversial subjects we have been holding off on debating all over again? smile

Well, we've already started talking a fair amount about EE 15 in the crowdforging forums about Upkeep, Upgrades, DI and Taxes. Aside from my needing to distribute out the remaining structure kits (including those just rewarded), I think that covers the bulk of the topics for upgrading settlements/structures.

Of the other items originally listed for EE 15, Selectable Alignment was already delivered in EE 13, leaving the Claim Tickets and the Core Rulebook. As we've been looking into the Claim Tickets, it looks more and more like we should hold off on them until Enchanting is done (currently scheduled for EE 16), since both X's of Holding and Y's of Protection are included in that system. For the Core Rulebook, we're thinking about pushing that off for the moment in favor of tackling other features, likely including social tools, first.

Beyond that, we're still working on our own thoughts about what the schedule is for delivering EE 15 (structure upgrades are already partially working, but still more work, and particularly testing, to do), as well as revisions to the remaining Road Map. We'll post discussion threads on various topics as we're feeling the need for discussion on them, but feel free to start any discussion threads of your own at this point.
Bob
Flari-Merchant
It doesn't mean much that a settlement can have zero buildings because the server(in general) is willing to allow anyone to train and craft at their facilities…

Ultimately, we always expected most settlements to be pretty open in terms of letting outsiders use their facilities, since doing so will let them bring in more tax money (starting in EE 15). Going without buildings means both turning down those possible earnings, and having to pay others to use their facilities.
Bob
Congratulations to Dun Baile, High Road, Phaeros and Staalgard for clearing their Over the Crowns! Nobody topped out at completing Stage 6, while 14 settlements completed Stage 7, all of whom will be receiving their choice of kits for a small and a medium structure, each in both +3 and +4 versions! Here's a complete list of settlements receiving those rewards:

  • Alderwag
  • Aragon
  • Blackwood Glade
  • Caer Coedwig
  • Carpe Noctem
  • Dun Baile
  • Fort Ouroboros
  • High Road
  • Keeper's Pass
  • Mediash
  • Ozem's Vigil
  • Phaeros
  • Staalgard
  • University Commons

With everyone understandably focused on killing ninjas, no other escalations beyond those finishing Stage 7 were cleared yesterday. Here's the total numbers that made it to each stage by the end:

  • Stage 1: 36
  • Stage 2: 31
  • Stage 3: 26
  • Stage 4: 23
  • Stage 5: 18
  • Stage 6: 14
  • Stage 7: 14
  • Finished: 14
Bob
Lisa Stevens
Bob
Flari-Merchant
Were there times when you thought we might not make 10?

I was always pretty sure you'd make it, since things were generally proceeding at a pace that would get you to 10. Still, finishing that close to the deadline did make me a little nervous. You never know what could come up at the last minute.

How about 14 Over The Crowns? smile

-Lisa

I was hoping things would fall in the "more than 10, less than 20" range, but with that escalation being such a challenge, I thought there was a pretty good chance of barely going over 10. Very impressed that all 14 hexes reaching Stage 6 also made it all the way through Stage 7! I expected there'd be a few ninjas still left roaming the land when this was all done, clearly there was a lot of coordination involved to avoid that.
Bob
Flari-Merchant
Were there times when you thought we might not make 10?

I was always pretty sure you'd make it, since things were generally proceeding at a pace that would get you to 10. Still, finishing that close to the deadline did make me a little nervous. You never know what could come up at the last minute.
Bob
HowardWdW
Bob, this system means that a settlement with lower level buildings will pay less in bulk resources to have
support at level 20 than a fully developed city. Is that your intention? Can the city effectively have no buildings and still be set at level 20 and pay 750 of each bulk (using your numbers) while a developed city has to pay more for level 20 support? Is a plus X keep required to be able to set support at a certain level? Is anything required in order to set support at a certain level?

I don't think it seems fair for an undeveloped city to be able to set support at the same level as a developed city if that is indeed the correct interpretation of your explanations.

Basically, given how important support clearly was to people, we didn't want to create a situation where high-level players would always stay in the bigger settlements because smaller ones couldn't offer them adequate support. This system offers those settlements the option of paying a significant amount extra just to get that support. However, they're not getting extra training levels out of that, or higher facility ratings, so they shouldn't have to pay as much.

That said, we're looking at a system to ease this change in, since there's still a lot of structure kit creation to do, and since it takes a while to build up the DI for upgrading structures. Currently, all your buildings have their trainer levels and facility ratings set based on Settlement Level. Eventually, trainer level and facility rating will be set entirely by a building's upgrades. What we're thinking of doing is initially saying that higher settlement levels offer a bonus to each building's trainer level and facility rating, with that bonus dropping steadily over the course of a few months until it's completely gone.

My current thought is that the bonus would start at +6 for trainer levels and +150 for facility ratings, dropping by 1 and 25 respectively every month. The bonuses could never take you above the training level and facility rating that are currently associated with each settlement level, though a structure that's already above those points without the bonuses wouldn't get reduced down.

So, to get your training levels to 20 when the system first ships, you'd just need to get your structures to +2, as long as you're willing to pay the extra for support to settlement level 20. In a couple months you'd need +3's, then +4's, and finally +5's.

This would admittedly minimize the incentive to get your buildings to +5 ahead of that schedule, so I'd still like for there to be some advantages to having more highly-upgraded structures. One thing I can do fairly easily is to use structure upgrades instead of settlement level when calculating settlement defenses (I'll have to adjust that part of the system anyway when upgrades become available). There may be some other relatively simple things we can implement to help with this issue.