Jump to content
  • Sign Up


  • Content Count

  • Joined

  • Last visited

  • Days Won


thelee last won the day on September 21

thelee had the most liked content!

Community Reputation

1,662 Excellent


About thelee

  • Rank

Profile Information

  • Steam


  • Pillars of Eternity Backer Badge
  • Pillars of Eternity Kickstarter Badge
  • Deadfire Backer Badge
  • Deadfire Fig Backer

Recent Profile Visitors

2,877 profile views
  1. ranger's Takedown Combo is an under-appreciated combo (literally), because I think as a community we just discovered it relatively late. Basically, takedown combo will increase +100% the damage done by DoTs as well, but doesn't get consumed by a simple DoT application or tick (it will get consumed by a DoT that has an initial attack, but you can just use the takedown combo after the initial application then). Works great with Disintegration and Cleansing Flame. I'll bet it would also be amazing with CCS since it ticks so frequently for decent damage.
  2. https://gamefaqs.gamespot.com/pc/227477-pillars-of-eternity-ii-deadfire/faqs/76599/inversions
  3. yes, your summary is my suspicion. though it doesn't explain your observation. ¯\_(ツ)_/¯
  4. so there's some sort of delay, and I think there are several causes. I haven't tested it extensively. At the very least, I think if you do an action manually there's a brief delay before the game realizes it should pick up on the AI script again. As for other possible mechanism: I have noticed something funky with my forbidden fist AI scripting. I initially put a 5s cooldown, a "safe" duration for forbidden fist. This was too much! As you might have noticed, it seemed like there was some additional delay. So I was missing opportunities to land an additional forbidden fist, well after the existing debuff wore off. I essentially fixed it by setting a 1s or so cooldown. That works just fine. (I forget the reason why I didn't just have it at 0.) At the time, I chalked it up the following reason: the AI decides on the next action as it completes the current action, not when it's about to do the next action. Example: monk dual wielding. Uses forbidden fist, triggers 5s cooldown. Auto attacks a couple times. On the n-th auto-attack, the forbidden fist script cooldown will expire in .1s. However, the AI script is evaluated right now right as the auto-attack completes, so it queues up another autoattack. So even though the forbidden fist action is ready for the next attack by the time recovery is finished, the AI has already decided to commit to another autoattack, and won't change its mind until it completes this queued up action (or you interrupt it by doing something else). So it's not recovery time per se, but just when the AI commits to an action (so it's not a cooldown, since interrupting it [edit - even literally an actual interrupt on the character] and resuming AI would queue up the correct action regardless of remaining recovery). Though please don't take this as a source of truth - this was a working explanation had at the time, and I didn't test it anymore because setting the cooldown to 1-2s was "good enough" for my purposes. It would make sense with what you're experiencing/your hypothesis, though.
  5. No way to do it I'm afraid. This is one of my great sadnesses in deadfire. They are basically only useful for in-map skill checks, but many (if not most) of the hardest skill checks are in interactive events that are triggered from the world map.
  6. by default, this is not really possible. as someone who has played lots of priests, this is my curse (holy radiance and consecrated grounds are the biggest AI scripting misses here). the only thing I can think of is to preface all rejuvenation and "spine of thicket green" effects with the same conditional (e.g. self: health < 50%) and preface all storm and "lord darren's voulge" effects with a different, exclusive conditional (e.g. self: health > 50%). then you could have your weapon switch be the top conditional block and have a cooldown of 1s so your character always switches to it if needed before doing anything else. (the trick here is that the conditionals have to be truly exclusive, even when considering target types of the abilities. for that reason i think "self" conditionals are the easiest since there's no ambiguity about the target) unfortunately, this is not ideal, but what you're suggesting is probably too sophisticated for vanilla AI scripting. neither do i. chanters are the one class I don't AI script at all, just autoattack.
  7. oh yeah, this one: i'm not very familiar with mods and generally don't use them. i'm like the worst person to ask. i do know that there has been some "full AI scripting" mod or two out there that greatly expands what one is capable of. In some of my more frustrated moments, this is the mod I most contemplate actually installing. (In the past I've used a few bug fixing mods.) I actually don't know about achievement-disabling. Normally I care about this a lot, even if i have all achievements, because it suggests to me I'm doing something I shouldn't :). But I clearly didn't have much of a problem of using a few bug fixing mods in the past. So maybe not. Again, I'm like the worst person to ask on this front
  8. i don't have much experience with scripting the attack command, i think the biggest risk here is that there's no way to do a delay, so assuming that this is a "always true" conditional, what could happen is that you do smoke, then you trigger an attack, but before your character has a chance to do an attack, another smoke is triggered, and then you do an attack. i honestly don't know. this is something that i think you basically have to test yourself to see if it works. if it works, great. if it doesn't, maybe you could gate #4 and #5 on having a target with <100% health (which would happen after 2 and 3, assuming this all happens at the start of a fight). probably i would choose different priorities for the target, e.g. nearest target, lowest health, lowest fortitude, hoping that they apply to different enemies. you could also try "best threat" or whatever that is, that might be semi-smart targeting.
  9. ok, i've been busy at work so i can't really test this in-game, but after some reflection, here's my best explanation that is consistent with what i've done in the past. i think what happens is that the game is checking all the conditionals in order of priority (so if a conditional is "target" it is looking at all possible targets, ally or enemy). if a block matches a conditional, it evaluates each ability in order, and passes it a list of targets that met the conditional, filtered by target type, and ordered by priority. The only exception is "target type: self" which always passes the target check targeting yourself. so here's an example, semi-nonsensical block (using my own conditional to be illustrative): conditional: target health < 50% cooldown: 10s abilities: cast:Restore, target type: ally or self, prioritize by: lowest health cast:Holy Radiance, target type:self, prioritize by: lowest health cast:Divine Mark, target type: enemy, prioritize by: highest health so if in a fight, let's say some silly enemy casts delayed fireball, and it explodes and puts enemies A into near death and B into bloodied and party members Xoti into near death, Eder into bloodied, but You are still healthy. The game checks the conditional and gets a list of targets, e.g. [A, B, Xoti, Eder]. Because it has a non-zero number of targets, it moves to the abilities list. It checks against ability #1 and sees whether anything is possible. Restore gets as valid targets ordered in priority [Xoti, Eder]. so it'd cast restore on xoti. Let's say you don't have a restore available. It moves to ability #2 and sees whether anything is possible. Now you get Holy Radiance cast on self, which always has a valid target, so you'd get Holy Radiance cast (even though you're healthy). Let's say you already have Holy Radiance used. Then you get the final slot, which is Divine Mark cast on [B, A] in order, which would mean Divine Mark cast on B. So I believe you're right in the sense that the meaning of "target (not) <50%" changes from ability to ability, but really what's happening is that the game tosses a list of *all* possible targets to the ability, and the ability target type and ordering is responsible for filtering it down to a non-empty list (and if it's empty, the ability is skipped, unless it's target:self targeting). Ordinarily we're not mixing ally/self target types and enemy target types in the ability lists so this ambiguity doesn't frequently crop up. So for your example, I think what that means is that you would use Smoke/Invisible as soon as any target exists with {not} <50% health, regardless of what your own health is. If you don't have smoke/invis avilable, then you would shoot you arquebus at one of the targets with {not} less than 50% health, prioritized by your priority selection. This is my best guess, consistent with how I've used scripting in the past. Notably IIRC the default priest-cautious scripts hae two separate healing blocks, one that conditions on target health, and another on self health, simply because of how generous the self-targeting spell cast rules are, so either the default scripts (or the copy-edits I made, I forget which) want to make sure you're not just casting e.g. consecrated ground when you're out of range of anyone who's actually hurt. edit: this would explain why my wizard script of "target: is spellcaster -> cast arcane reflection" is basically equivalent to "always true -> cast arcane reflection". from the perspective of the game my party always has a spellcaster (the wizard) and there's nothing in the ability list to further filter to enemies only, only a self-cast that is always valid.
  10. i did my best to answer some of those questions, but unfortunately the vanilla AI scripting--while useful--is pretty limited. I think for some of the more sophisticated stuff you want to do you will definitely have to go with a mod.
  11. hm, i don't think this is possible. the only movement restriction that appears by default is the "can break engagement or not" checkbox. oof, that is a very good question. i think the conditional is sort of a poor-abstraction as to what's going on behind the scenes, because sometimes it just doesn't make sense. I think what happens is much closer to your last statement. E.G. if the block is "target health < 50" and you have as action 1. "restore target: self" and action 2 "divine mark, target: enemy, prioritize by: lowest deflection" with cooldown 10s. the fact that the two share the same conditional is meaningless - I think the UI grouping is a) purely a logical grouping for the user; b) to make it easier to gate common effects by a common cooldown and action priority. in practice, I suspect what ends up happening in the back end is that you create an action with UUID-1 "look at [target:self]; if [target:self].health < 50%, cast restore, activate cooldown TIMER-1" and then a second action UUID-2 "only if TIMER-1 not activated; look at [target:any enemy]; if [target:any enemy].health < 50%, add to [a list of targets]; choose target form [a list of targets] with [lowest deflection]. cast divine mark. activate cooldown TIMER-1." i think in cases where you add a non-targeted ability to a block that has a target (e.g. if in that same target health < 50 or whatever, you also added a "weapon switch" action), it effectively turns into a "always true" conditional, that just happens to share a logical group and cooldown timer with others that have actually have a relevant conditional. i think this could easily be tested more, but that's my best educated guess. edit: i crossed this all out, because upon reflection it contradicts something else i've been able to do with conditionals. i have to think about this more. it's one attack. red hand's 2 shot before reload is rare enough that i suspect you might hit bugs if you try to script anything special about its behavior. no, unfortunately, this is really only possible with inspirations/afflictions where you can negate a conditional about their existence. sometimes you can do "best target/threat" and that randomize a bit, or you can add a target priority that will have lots of ties and hope for a semi-random selection, but in situations like this I just effectively use an AI script to take care of hte first target for me, and then I have to micromanage successive targets (like with a long cooldown or a particularly restrictive conditional). get a mod?
  12. Without a mod this is pretty impossible. There's no conditional to let you detect max focus or the ascended status. My only solution has been to micromanage the cipher a lot.
  13. Pre-sales exceeded PoE1, but then post-release sales cratered. So there was definitely some sort of bifurcation in the market about people were enthusiastic about the game versus everyone else. i think people just have extremely selective memories on everything related to game releases. I think, at best, Deadfire could've delayed like a few weeks because their first patch was such a huge nerf hammer that it left a sour taste in a lot of people's mouths - clearly they thought it was needed but for some reason could not bring it together quickly enough to make it a day-0 patch. that's about as far as i can see it. but aside from that, deadfire was an incredibly stable and polished game, and only got better from that. wasteland 3 (which i've been playing recently) is an incredible mess - ridiculously trivial things are busted [like keybindings, and even simple controller detection] and major tentpoles were/are nonfunctional at release [co-op]. even pathfinder:kingmaker, which has taken lot more sales than deadfire and many more years of patches is still jankier and buggier than deadfire. not everyone can be like bethesda, blizzard, or valve and have the luxury of constant steady revenue to allow them to endlessly tinker on a AAA product for years on end (and even then, bethesda still releases extremely buggy games). For a smaller studio, "just wait 9 months" can be a death sentence. That's the only explanation that I have, for example, that Wasteland 3 came out now when it did even with such basic things broken - they basically needed to keep the lights on in-house and they would have missed the last part of the summer, where game sales are easier. And for the record, both PoE1 and Deadfire *were* delayed for polish. What you got was actually the stable versions of the game. Both were slated for more like christmas releases, and both got delayed because of bug fixes and such. Obsidian was in such dire straits the first time around that Feargus told the leads at the time that if they missed the delayed deadline they'd have to quit on the spot. The version of the game one would be comparing against is the one that almost got released on christmas, not some hypothetical mythical one that came around another 9 months after their actual release. (By the way, many of the patch changes that came out after release were in response to player feedback, which is by definition not something you can do without a wide release. Some of the patch changes were intended to be after-release updates as well, to keep up player engagement, in the vein of "games as a service.")
  14. if i remember correctly, queen's berth has some, i think either one of the outdoor vendors near the docks or the tavern owner in the wild mare stocks a couple sugar. i might be mistaking it for salt (icons are too similar), but in my last run i always did a shopping trip in nekataka and found myself always able to make stuff like glazed pork.
  • Create New...