Jump to content

Ulb

Members
  • Posts

    319
  • Joined

  • Last visited

Posts posted by Ulb

  1. Davaeorn script seems bugged (SR install, EET). He constantly uses Dimension jump rather than offensive spells.

     

    It's not just Davaeron but Andris as well (for me at least).

    Important to note though that this is not a new bug since it is present in my old install with this version:

    VERSION ~v30 BWP fix + K4thos' EET compatibility + kreso's Spell Revisions compatibility~

     

    *edit* To clarify: I do not have a v32 install, I'm only adding that I have experienced the same/a smiliar bug as kreso on my last install...

  2. I forgot to mention it earlier, but about that insect change..I really don't like it. (Seems to be a pattern here, sorry for being such a spoil sport :p)

    I just don't see the point of it, neither thematically nor from a mechanical pov.

     

    Sure, being attacked by a swarm of insects would probably make you go "berserk" in the sense of furiously flailing and bashing around, in order to rid yourself of the insects. It sure as hell wouldn't make you randomly run up to the next best person and start attacking them (while merrily ignoring the insects biting away at you).

     

    The target should be seen running around, being occupied with the insects and hardly able to do anything else.

    Fear simulates that situation perfectly while berserk doesn't make any sense.

     

     

    If you're not soloing, but have no means to revert petrification, you'll be stuck (can't travel between areas) and the only way to proceed is to kill petrified character.

     

     

    No, you can just remove them from your party and travel on.

     

    FtS as it is right now in SR is fine. It gives prepared parties a chance to counter/handle the effect without disrupting party banter/npc story progressions. I don't see why the argument of "but what about unprepared parties?" is valid in any way. Following that line of thought you would have to do away with all kinds of spell protections as well because parties might not have prepared to have a way to dispell them...

     

  3. @Ulb

     

    I don't understand what's the differnece in case you're solo. Domination = instant death = stoning = permanent hold = feeblemind etc. In all cases, it's game over.

    I can get around permanent/item equiped immunities, that's not an issue.

     

    I'm not sure what difference you're talking about?

     

    You said you changed FtS to "hold and then kills you in 5 rounds" because you wanted to keep the game-over effect for solo players. I was merely suggesting one way to achieve that effect without fundamentally chaning what FtS does and deviating from the game's lore.

  4. You might try the SCSs sub form here on the board or you might try Roxanne's personal forum (there is a link in the first post).

     

    Have you recently updated to 2.5 via GoG? I've heard the patch over there is actually missing some files. In that cae, doing a complete re-install (with the full installers instead of the update patches) might solve your problem.

  5. @Ulb, @Bartimaeus

     

    If you have better suggestions for petrification handling, say. In vanilla, petrified PCs would often crash for no reason, and any damage would crash the statue.

    Domination will end the game, yes, but that's hardly a solution. What if you're not soloing and don't have means to cure petrification? Why would someone be dominated after being stoned?

     

    Petrification should not have a limited duration but, in any case, the domination effect would obviously have the same duration as the other effects and be removed by the same spells. I can't see any downside to my solution. It will emulate the game-over effect of the original FtS while having virtually no negative downside, allowing SR to keep a version of FtS that's actually in line with the game lore and what player's could reasonable expect from a spell with that name.

     

    *edit* Without looking it up, I'm not sure if there is an opcode that the player usually can't get protection from. If there is not, players protected from domination would obviously pose a problem to my solution...

  6. - Flesh to Stone will kill the target after 5 rounds have passed if not cured

     

     

    I hate this change, mainly because it goes against what the game tells us about how petrification effects work like.

    In the BG series being turned to stone does not kill you. Branwen, the girl in the Temple area and the party in BG are all more or less fine after being released.

     

    You say the main reason for this change is to prevent situations where solo players get stuck, but how is the death screen not showing up more immersion breaking than a petrified character just dropping dead after 5 rounds, even if you ignore my first point?

     

    Maybe you could solve the solo/death problem by adding a domination effect, that should also cause the game to end if there are no other player characters.

     

     

    Ice Storm is still deflected :) . It's only 3 rounds, so I let it be.

     

     

     

    This seems very inconsistent to me. Not a big fan of having "general rules" like what does and does not get deflected change on a spell by spell basis, possibly without any ingame information about it.

     

     

    + 4 AC/Thac0, 20 HP and Fear immunity isn't enough to warrant a 6th level slot?

     

     

    Probably good enough, but is it interesting enough and fits thematically?

    It just looks a bit boring to me and also like something that's more on the cleric side than what mages should do.

  7. Roxanne is still welcome as Roxanne to G3. She is not banned or anything.

    I know and I didn't mean to imply that she should be or anything.

     

    We'll just be diligent about letting newcomers to the thread know that they may find faster help at the support link in the OP rather than here.

     

    Right, which was the point of my initial post. The opening post really doesn't convey that an answer from Roxanne can not be expected any time soon. Thus, a disclaimer of some sort might be warranted.

  8.  

    If you would bother to read the above post. If you notice, it already assumes to not get a direct answer, as there's an thanks already.

     

    Seems to me, with each passing day, you stray further from logic and reason.

     

    Just close the thread. Roxanne is providing support on her own website, people would be better served looking for help there.

    I agree, that would probably be the best course of action.

  9. Since Roxanne is apparently not going to come back to this thread, maybe something should be done to the opening post to make people coming in aware of that?

    There is a link to her homepage in the opening post but still, this IS a support topic and it being here on the EET forum, it makes sense that people would expect to get answers and be heard?

  10. I set it in the area file first, which caused Rain rather than Snow.

     

    For the second attempt I added;

     

    IF

    OnCreation()

    THEN

    RESPONSE #100

    Weather(SNOW)

    END

     

    to the area's script. That way DOES result in snow, but I don't know how to set a duration on it. The snow stops as soon as I rest, I haven't checked how long the snow will last if I leave the game unpaused and just let it run.

     

    I'm not sure how to set a duration using that Action. If anyone knows how please post an example.

     

    Well... why not just loop that script block once per round or so... should get the job done, right?

  11.  

    "In range" as in, much closer? Or "in range", as in, currently hitting them with their axe? SCS uses Range=4 as its normal trigger to engage (i.e. all enemies within Range=4 are attacked before seeking out anyone further away). And gnolls use the same AI as anyone else (at least, those gnolls affected by SCS, which should be basically all the ones in vanilla BG but won't catch any added by Beamdog).

     

     

    Hm, that is how I remember it. I seem to remember them stopping their melee attacks and start going after ranged characters.

    I really don't want to send you on a wild goose chase based on what might just be my faulty memory though. So, unless other people report the same, it might not be worth looking into it any further.

    Based on what you've said, what could have happened instead is that the Gnolls (and other melee based enemies) already picked their (ranged) target at the start of the encounter and simply ignored characters that entered their melee range and continued to pursue the ranged characters.

    How often do SCS enemies re-evaluate their target once they are in pursuit?

  12. As the title says, is there a good way to prevent a shaman kit from getting to select spells during the level up (and character creation if possible)?

    I know the two common ways are to either remove spells after the level up via clab file or flag all spells cleric/druid exclusive and then patch all kits to gain appropriate spells but I find neither of those solutions satisfactory.

    The first solution would keep the spell selection process during the level up and the second way seems tedious and prone to compatibility issues, so I'm hoping against all odds there might a better solution..

  13. You could/might even be able to set up a second "dummy" spell that's being cast from the first spell and does nothing but "burn" the appropriate amount of spell levels when cast on enemies, if you really wanted to prevent people from failing to burn off spell protections by spamming Protection from Evil at enemies..

  14. So, seeing as you're currently working on a new version I thought I bring up two points that bother me about SCS behavior.

    Now, this is just from the top of my head since I haven't actually played in a while and I never really investigated if all of those issues really are part of SCS. (They are though, at the very least, present while SCSs is installed.)

     

    Still, better to mention it now while it might be of some use to you then later once SCS32 is finished, right?

     

    1.

    SCS mages (liches) will teleport to party members that are off screen and have never even engaged with the lich. To me this is SCS actually cheating.

    There is no in-game explanation for the lich to know where my party members are, nor is there a good reason for them to even start looking for them in the first place.

    I get that it's probably there to avoid cheese tactics but IMHO this behavior severely punishes party play-throughs (compared to solo players) since protecting a whole party (that is also at a lower level than a solo player would be) is significantly harder than just protecting one character. (And worse, it is also significantly more “effort” on the player.)

    If SCS wants to continue having the AI teleport to party members off screen, enemy casters should at least have to spent time to cast some divination spell a'la far sight or wizard's eye and then have a percentage chance to successfully “discover” party members.

     

    2.

    Undead controlled by a cleric behave like they are charmed instead of dominated and will also randomly start to re-engage party members even though they are still controlled.

    This appears to be unintended behavior and to be honest I'm not sure how much of it is SCS's doing/fault and how much is hardcoded.

    In any case it is something that does happen with SCS installed so it might be worth to look into.

     

    With good clerics outright destroying undead creatures I don't think evil turn undead should “only” charm undead instead of dominating them. (What I mean by this is that controlled undead will break free if they are harmed by the party.)

    Doesn't make sense lore wise either, since you're not magically making them think you're their friend, you're out right controlling them.

     

    With controlled undead also attacking party members it would seem like their scripts aren't properly detecting them being controlled or not account for it at all.

     

    On a side note: Controlled liches behave really wonky. They will also still occasionally cast spells at the party and they constantly get their meteors refreshed which looks very immersion breaking.

    Now, I get that this is less of a concern since you usually don't really get to the point where controlling liches is a viable option but since the EEs introduced the new Opcode to buff turn undead levels it might be worthwhile to also look into to avoid issues with mods that might use that effect.

  15.  

    It doesn't. SubspellA reducing the caster's hp should be cast no matter what. Thus, the 146 effect comes first. The 318 effect is next, and if the conditions are met (not enough hp) then the rest of the spell - the actual Produce Fire part - doesn't happen. The idea is, if you try the use the ability without enough energy reserves, it misfires and you get hurt. (SubspellA has conditions handling this... basically it does nonlethal damage to you, so you knock yourself unconscious.)

     

    Ah, okay didn't get that it is supposed to always damage and that the spell takes care about preventing leathal.

     

    As for your problem, have you tried simply chaning the target to original caster? I would assume that works.

     

    It's weird, I have this working just fine for single-target abilities; I target a creature, and the main spell affects me while a subspell affects the creature. For some reason going from single-target to an area effect is throwing me. Presumably because the latter requires use of a projectile while the former doesn't.

     

    Yeah, I can only guess but maybe the engine handles that "at any point" as if the spell was an area projectile affecting anyone within range of target point. I agree though it is inconsistent with what one would expectr from how single target spells work. On the other hand.. if it worked like that the spell should also make all creatures cast subspellB, is that the case?

  16. Spell1 has:

    - header target = any location

    - no projectile

    - effect 1 = opcode 146, cast spell, target = self, resource = SubspellA

    - effect 2 = opcode 318, target = self, condition = not enough hp, resource = Spell1

    - effect 3 = opcode 148, cast spell at point, target = preset target, resource = SubspellB

     

    SubspellA has

    - target = self, 6 points damage, reduce max hp by 6

     

    SubspellB has:

    - header target = any location

    - projectile = Produce Fire projectile (affects anyone in ~15' diameter

    - effect 1 = fire damage, target = preset target

     

     

    Maybe I'm missing something but I'm really confused how your spell1's second effect is supposed to protect the caster from its first effect in any case?

     

    For whatever reason, it seems like anyone affected by the Produce Fire projectile is losing 6 hp/max hp - they're being affected by SubspellA.

     

    Are they really though? I would assume everyone is affected by Spell1. You could test this by just reducing subB's projectile range to 1 or something and see if targets outside are still affected.

     

    For me it looks like your Spell1 with its target set to any point within range will affect anyone within your set range (which makes sense) and since your second effect can never protect anyone from the first effect- which will already have been resolved at that point- anyone gets hit by SubspellA.

  17. It sure seems strange to not keep none-EET compatibility, I'll admit that (I haven't really looked into it, so I wasn't aware).

    But still, there previously only was a none-EET compatible version (I assume?) and now there is also one that works for EET. Having to download a different version depending on your set-up may be less convenient but it is still better than simply not having a working version for EET at all. So, in the end, I still consider it an upgrade and very much in the spirit of Kulyok's post.

×
×
  • Create New...