Jump to content

NEW Project: Sacred 2 Purist Fixpack


Flix

Recommended Posts

2 hours ago, Lindor said:

The other half, which is Hunting Fever 1 already appearing in the logbook from the start of the game, can probably be fixed with some lua scripting. The cause for that issue is still a mystery however, so it would be treating the symptoms and not the desease.

I am fairly certain this problem only exists for legacy characters, due to some vanilla quest flags being stored in the character save files.  As such I'm not too worried about that.  It's the other part, the triggering when accepting other kill quests, that is troublesome.

Link to comment
11 hours ago, Flix said:

It's the other part, the triggering when accepting other kill quests, that is troublesome.

Here's how to fix that: in the function CM_TimedKillCheatEvent change the line

if (cm_dcount<=cm_qkills) and (cm_dcount>=0) then

to

if (cm_dcount<=cm_qkills) and (cm_dcount>0) then

This will prevent it from triggering the timer upon accepting other quests. If the quest is part of the logbook from the start of the game, then the first kill of whatever you're supposed to kill will start the timer.

Another pleasant side effect of this fix is that now the messages will appear correctly if the timer is started via the CM_TimedKillCheatEvent function. Differently to what I speculated, changing anyofthem=1 to anyofthem=0 has no effect on the messages, so I highly recommend it, it's a useless line at best and a broken line at worst.

11 hours ago, Flix said:

I am fairly certain this problem only exists for legacy characters, due to some vanilla quest flags being stored in the character save files.

There are two things which smell to me like a lua bug:

  1. I used the CM-Patch test characters and NOT the Ice & Blood test characters to trigger the bug.
  2. The quest in question, Hunting Fever 1, is the first entry of the cm_timequest table. The table contains only 10 elements though, but still that's a classical lua bug sign

There are only two events in question who could possibly cause that bug: "OnSetup", "OnRespawn", "OnPrecondsFulfilled" and "OnTaskAwaiting". All functions triggering on one of those events, being it directly or indirectly, need to be checked.

Link to comment
17 hours ago, Lindor said:

These sets of functions are triggered on the (hardcoded) "OnCounter" event of the quest. This "OnCounter" event SHOULD only fire upon killing one of the creatures of the "kill-these-creatures"-quest. However, somehow this event is also fired upon accepting a new quest. If you're able to prevent that from happening, then you have half of the fix.

I found out what's going on here. Accepting new quests does not fire the "OnCounter" event. the set of functions mentioned are not only triggered by this event, they're also triggered by the CM_AllTimerResolve() function which is triggered by the CM_GarbageCollect() function which is triggered upon accepting quests. Any quests, not just kill quests. Don't worry, this new knowledge doesn't interfere with the above fix, I tested the above fix very precisely before I posted it.

I might have a solution for the second half of the problem as well, just need to implement and test it.

EDIT: It does not work. I tried everything I have in my repertoire, from applying additional checks to changing the quest id. Seems that you're right and it's not fixable in the scripts. But at least the first half has a fix now.

Edited by Lindor
Link to comment

Purist Fixpack version 1.2 is now released!  All links have been updated in the lead post.

Thanks to a particularly thorough bug reporter on Steam, and the diligent efforts of Lindor we have smashed a few more bugs. Also present are some missing NPC voiced lines thanks to Dmitriy's findings.

  •  Fixed Haenir not spawning at the end of the Northland Expedition quest.
  •  Fixed non-hostile ghosts spawning from graves.
  •  Fixed non-hostile Goblin Boar Riders in the cave east of Ruka.
  •  Fixed Hunting Fever being triggered by accepting random unrelated quests.
  •  Hunting Fever III reworked. Seraphim Diana now appears in the correct spot to initiate the quest, and the player will report back to her in the same location.
  •  Enabled various shouts, taunts, and other missing voiced lines for NPCs during combat. This also affects missing ambient wildlife sounds.
  •  Fixed icon size for Endijian's Javelin.
  •  Fixed nearly invisible icon for Leather Hat Trophy.
  •  Fixed missing icon for a random magic 1h sword.
  •  Fixed Leaping Plant attack range being halved.
  • Like! 1
Link to comment

Damn. I got so consumed by playing Sacred 1 that this has escaped my mind almost completely. Was expecting to take a break from Sacred 1 by around the half of January, but alas, addiction runs deep.

Incredible to see the amount of work and effort being put into this. Had great fun reading about the findings regarding the Hunting Fever quests. I remember it always starting the counter at seemingly absolutely random points and polluting the quest log from the start. Great to finally know why that was and seeing attempts at fixing it.

I will put off my Seraphim Sacred 1 playthrough and dive into this over the weekend. Will be interesting, as I intend to play with the vanilla s2render.dll for the original animation blending speed. Hopefully, everything works OK even if I do that.

Will probably fire up a ranged Shadow Warrior or Seraphim to see how it interacts with the changed (massively buffed) ranged versions of Frenzied Rampage and Pelting Strikes. When I was playing with the CM Patch, I remember it causing issues when I swapped to the vanilla renderer.dll file on an existing character. My Seraphim refused to fire the BFG completely but when I made a new one, it worked fine.

 

And one additional question. I'd like to ask about the actual difference between normal Elite Textures and Trimmed. What exactly is "trimmed"? Is there an actual visual difference in game when comparing normal vs trimmed? Or is it just optimization without visible effects? I played the CM Patch with the full Elite Textures, which did result in an occasional crash, but at a frequency low enough that it was acceptable.

I just finished a fresh Sacred 2 install from GOG and downloaded the patch and Elite Textures. Will dive into it tomorrow.

Edited by idbeholdME
Link to comment
15 minutes ago, idbeholdME said:

Will be interesting, as I intend to play with the vanilla s2render.dll for the original animation blending speed. Hopefully, everything works OK even if I do that.

Should be fine. Most of what's in that file is just quality of life visual enhancements.  Elemental VFX on projectiles, missing DOT FX, that kind of thing.

15 minutes ago, idbeholdME said:

I'd like to ask about the actual difference between normal Elite Texture and Trimmed. What exactly is "trimmed"?

The Elite normal maps are removed. The result is massive reduction in file size (and therefore the game's memory cache is not taxed so badly) without any noticeable visual change.  The reason you can't see a difference is because the default normal maps were already perfectly large enough to convey the detail and texture they are designed for.  Normal maps give an illusion of depth and height, even on a 2D image.

By contrast the Elite diffuse maps are all preserved, since these are where the visual perception of increased quality comes from. This is where you'll see sharper, clearer textures with better quality without the blurriness or graininess of the lower-res textures.

If performance is crash-free and acceptable to you, say, in the crowded Griffinborough streets, by all means stick with the official Elite textures.  PFP contains some fixes for the worst offenders of the stock normal maps (many, many compression faults were fixed). In other words with the PFP you're already getting some improvement to Elite Texture performance even with the vanilla pack.

I for one notice an improvement even on a current-gen PC and could likely never go back from the Trimmed set.

  • Like! 1
Link to comment
6 minutes ago, Flix said:

The Elite normal maps are removed. The result is massive reduction in file size (and therefore the game's memory cache is not taxed so badly) without any noticeable visual change.  The reason you can't see a difference is because the default normal maps were already perfectly large enough to convey the detail and texture they are designed for.  Normal maps give an illusion of depth and height, even on a 2D image.

By contrast the Elite diffuse maps are all preserved, since these are where the visual perception of increased quality comes from. This is where you'll see sharper, clearer textures with better quality without the blurriness or graininess of the lower-res textures.

If performance is crash-free and acceptable to you, say, in the crowded Griffinborough streets, by all means stick with the official Elite textures.  I for one notice an improvement even on a current-gen PC and could likely never go back from the Trimmed set.

Thanks for the thorough explanation. The way it behaved was that the longer the game was running, the more likely it would be to crash. If I visited a crowded city within an hour of loading the game, it would occasionally stutter, but not crash. If I came back to the city after 2 hours of walking around in the wild, it would eventually crash. But besides these very crowded city areas with tons of objects and therefore textures, I had no issues with the normal Elite Textures.

I'll probably start with the normal ones and swap to trimmed if it becomes too annoying.

Link to comment
15 hours ago, Flix said:

Should be fine. Most of what's in that file is just quality of life visual enhancements.  Elemental VFX on projectiles, missing DOT FX, that kind of thing.

Forgot to ask one more thing about this. Is the vanilla s2render.dll the only file needed to properly restore the animation speeds? I noticed the fixpack also includes a different animations.txt script. Should I keep the one from the fixpack or also revert that one to the vanilla? I can't quite remember if it had any effect on that. But just casually looking over the animation definitions for the Seraphim in both files, there seem to be a ton of differences between the two.

Edited by idbeholdME
Link to comment
1 minute ago, idbeholdME said:

Forgot to ask one more thing about this. Is the vanilla s2render.dll the only file needed to properly restore the animation speeds? I noticed the fixpack also includes a different animations.txt script. Should I keep the one from the fixpack or also revert that one to the vanilla? I can't quite remember if it had any effect on that.

It's strictly the dll that's doing the work there.  Not to split hairs, but the actual animation timings defined in animation.txt are unchanged in the script.  Rather it's the hardcoded blending speed that's increased.

The fixes in the script are of a different nature, and they are myriad.

Link to comment

Question about the global.res

What does this file do? If I use it my whole game is in english, can I use the old german one?
I suppose it might just update the version number in the title screen, or are there more changes in that file?

Link to comment

It contains all the text corrections but only for the English version.  You may delete the "locale" folder entirely if your game install is another language.

Link to comment
3 hours ago, Flix said:

It's strictly the dll that's doing the work there.  Not to split hairs, but the actual animation timings defined in animation.txt are unchanged in the script.  Rather it's the hardcoded blending speed that's increased.

The fixes in the script are of a different nature, and they are myriad.

Well, I did a couple of tests and for one, using the vanilla animation.txt makes Pelting Strikes and Frenzied Rampage behave as they do in the vanilla (2 shots). This brings me back to the first post I made in this thread. Seeing as animation.txt is responsible, shouldn't it theoretically be somewhat easy to revert back to the original behavior of these 2 CAs by simply changing the corresponding entries to the vanilla definition for those who want to? If anyone knows which entries are ranged Pelting Strikes and Frenzied Rampage, it should be possible to just revert those 2 changes but keep all other fixes intact, correct? Unless some other big change was made to the animation definitions in general, which is quite possible, seeing as the vanilla animation file has 24 MBs and the one from CM/Fix Pack has barely 2.5 MBs.

And what I meant by differences in the animation file is this. Example entry 4 from the fix pack:

Spoiler

        ["entry4"] = 
        {
            ["name"] = "ANIM_TYPE_SM02_BOW",
            ["marker"] = 
            {
                ["ANIMSTART"] = 0.0000,
                ["SHOUT"] = 0.1200,
                ["ATTACK"] = 0.3200,
                ["ATTACK1"] = 0.4400,
                ["ATTACK2"] = 0.5600,
                ["ANIMEND"] = 0.8800,
            },
        },

And the same entry from vanilla:

Spoiler

["entry4"] = 
        {
            ["name"] = "ANIM_TYPE_SM02_BOW",
            ["overload"] = "ANIM_TYPE_ATTACKA_BOW",
        },

 

Or entry 7. Fix pack:

Spoiler

["entry7"] = 
        {
            ["name"] = "ANIM_TYPE_ATTACKA_GUN",
            ["marker"] = 
            {
                ["ANIMSTART"] = 0.0000,
                ["SHOUT"] = 0.1600,
                ["ATTACK"] = 0.3600,
                ["ANIMEND"] = 0.9200,
            },

Vanilla entry 7:

Spoiler

["entry7"] = 
        {
            ["name"] = "ANIM_TYPE_ATTACKA_GUN",
            ["marker"] = 
            {
                ["ANIMSTART"] = 0.0000,
                ["ATTACK"] = 0.1600,
                ["ANIMEND"] = 0.9200,
            },

 

 

Or entry 46. From fix pack:

Spoiler

["entry46"] = 
        {
            ["name"] = "ANIM_TYPE_DEFENSE_1H",
            ["marker"] = 
            {
                ["ANIMSTART"] = 0.0000,
                ["ANIMEND"] = 1.7600,
            },

And from Vanilla:

Spoiler

["entry46"] = 
        {
            ["name"] = "ANIM_TYPE_DEFENSE_1H",
            ["marker"] = 
            {
                ["ANIMSTART"] = 0.0000,
                ["ANIMEND"] = 1.5200,
            },

 

Edited by idbeholdME
Link to comment
27 minutes ago, idbeholdME said:

shouldn't it theoretically be somewhat easy to revert back to the original behavior of these 2 CAs by simply changing the corresponding entries to the vanilla values for those who want to?

Hmmm, give me a little bit and I'll cook something up.

  • Like! 1
Link to comment

@idbeholdME  Try this file:  https://drive.google.com/file/d/1xX1NbrGJ_CvfA5JHfmBhAElwzMbyGooe/view?usp=sharing

Overwrite the existing animation.txt in the mod folder, before enabling.

I think I see what went wrong, the intention was to add one extra hit, increasing from 2 to 3, but the CA automatically adds an extra one regardless of the amount of "ATTACK" entries in the animation, so it resulted in 4 total.

It should be back to 2 hits, though I scripted it differently, giving it its own animation rather than duplicating the standard attack animation as in vanilla.

The "SHOUT" entries you noted are meant to enable battle cries that may accompany special move animations.  There's probably more SHOUTs than are strictly necessary but the intention was to cover all the bases.

  • Like! 1
Link to comment
4 hours ago, Flix said:

@idbeholdME  Try this file:  https://drive.google.com/file/d/1xX1NbrGJ_CvfA5JHfmBhAElwzMbyGooe/view?usp=sharing

Overwrite the existing animation.txt in the mod folder, before enabling.

I think I see what went wrong, the intention was to add one extra hit, increasing from 2 to 3, but the CA automatically adds an extra one regardless of the amount of "ATTACK" entries in the animation, so it resulted in 4 total.

It should be back to 2 hits, though I scripted it differently, giving it its own animation rather than duplicating the standard attack animation as in vanilla.

The "SHOUT" entries you noted are meant to enable battle cries that may accompany special move animations.  There's probably more SHOUTs than are strictly necessary but the intention was to cover all the bases.

INCREDIBLE STUFF!!!. Seems to work perfectly. Pelting strikes is back to 2 shots, tried a bow and the BFG. Will try Frenzied Rampage in a bit. This would make a great addendum download for those who want completely unchanged CAs. As I've said before, the 4 or 5 shot salvo these CAs fired made using any other CA on a ranged Shadow Warrior and Seraphim completely pointless so it's awesome to finally have the option to revert back, without losing all the fixes in the community patches..

Otherwise, the 1.2 release seems to be working perfectly. Did various stuff in act 1 for a couple of hours and hasn't crashed once. I'm also playing with the Reduced Fog mod and the vanilla Physics (as someone mentioned before, I also like leaves and debris swirling around everywhere :) ).

 

One last thing on an unrelated note. This is not caused by the patch, but when playing in fullscreen mode and there is a loading (from the menu or entering a cave/dungeon, saving and exiting etc), instead of a smooth transition and showing a loading screen, the game always just freezes for the duration of the loading and then abruptly resumes once it's finished. Even when launching the game in fullscreen mode, it causes the first 2 logos to not show at all, only audio can be heard. The first visible thing is the nVidia logo and instead of showing right away, it slowly fades into view. When playing in windowed mode, everything works fine, including the intro logos. Is this just a "me" issue or does it happen to anyone else?

 

EDIT: Update on Frenzied Rampage

While Pelting Strikes seems fine and behaves as it should, Frenzied Rampage still seems somewhat finnicky. It still has the same animation as it did when it fired 4 or 5 projectiles, but the beginning of the animation does nothing and then fires 3 projectiles (bow). The sequence goes: Click to use FR - (animation starts) pause , RA... TA TA. The first projectile fires after the initial delay, then there is a tiny pause and the last 2 projectiles fire off in a very quick succession. If possible, please try to restore it to the original behavior like Pelting Strikes. It is quite possibly the last thing that remains from my wishlist :D

I checked the vanilla animation and that looks perfectly fine. He draws the bow and after a short pause, release 2 shots in a very quick succession. It even has a different cadence from ranged Pelting Strikes, which fires the first shot immediately and the second shortly after that. There is a bigger pause between the projectiles than for Frenzied Rampage but the total time seems very similar as Pelting Strikes does not have an initial delay and gives the 2 CAs a distinct feel. IMO, just restoring that one would be perfect.

Or even better. Just tell me which entries are for which Combat Art and I can probably do it myself. I can see how it works comparing all the 3 files. From what I can see, Pelting Strikes is the ANIM_TYPE_SM02 in the Seraphim section and Frenzied Rampage is ANIM_TYPE_SM07 in the "zenturio" (shadow warrior) section?

Edited by idbeholdME
  • Thanks! 1
Link to comment

I found a bug, either a display bug or a game mechanics bug and it might be present in all versions.

In addition to the Damage Converters (Chunk of Lava, Poison Fang, etc.), there are also pieces of armor that can have this property.

Interestingly, these change the damage type of the magical combat arts in the display.

I tested it with Shockwave against magic-resistant enemies, and unfortunately the damage was greatly reduced, indicating that the damage conversion isn't actually taking hold.

I think someone should take a look at that and try to find out which behavior is intended.

If a damage conversion of the spells were possible, for example, you could also play radiant pillar with poison conversion and strengthen the poison effect with damage lore, which would open up new possibilities but also change a lot.

zQCESHV.png

The conversion is not displayed for Archangel's Wrath, I think that's because it has its own conversion to fire.

Edited by Vishanka
Link to comment
2 hours ago, Flix said:

Oh, not to worry, it will just be part of the main mod once I'm sure it's working correctly.  In spite of my conviction that 2 piddly shots sucks I'm not trying to enhance the game in this project, just fix it.  :D

Vanilla Pelting Strikes and Frenzied Rampage actually don't feature any animation at all for ranged weapons, they simply recycle the standard left-click attack animation. I'll reset it back to that behavior.  I don't know why I was so sure there was a hardcoded reason for this, it seems so obvious how it works now that I'm looking at the script.

Let me know how this one performs please: https://drive.google.com/file/d/1_5FDPt23TkB-YHe8AChQ2Zrw00YCWSsm/view?usp=sharing

Indeed. I looked into the animation definitions myself and in vanilla, that is exactly what it does. Just launches 2 normal attacks. I tested it myself by just copying the animation definitions from the vanilla animations.txt and replacing the ones in the purist fixpack and it completely restored the vanilla behavior. SM07 was indeed Frenzied Rampage. Was about to start replacing it for all weapon types and also when mounted, but you beat me to it.

Once again, big thanks for looking into this. Off to test the new file now.

EDIT:

Seems OK now, at least behavior-wise. But upon checking the files, I noticed one thing off for Pelting Strikes. The BOW timings. Pelting Strikes has different values but as it in practice should just copy the normal attack, it should have the same timings too.

Spoiler

["entry3"] = 
        {
            ["name"] = "ANIM_TYPE_ATTACKA_BOW",
            ["marker"] = 
            {
                ["ANIMSTART"] = 0.0000,
                ["SHOUT"] = 0.1200,
                ["ATTACK"] = 0.1600,
                ["ANIMEND"] = 0.9600,

            },
        },
        ["entry4"] = 
        {
            ["name"] = "ANIM_TYPE_SM02_BOW",
            ["marker"] = 
            {
                ["ANIMSTART"] = 0.0000,
                ["SHOUT"] = 0.1200,
                ["ATTACK"] = 0.3200,
                ["ANIMEND"] = 0.8800,

            },

Or alternatively just use the way it's done in vanilla, so the override method:

["overload"] = "ANIM_TYPE_ATTACKA_BOW",

Also, I'm not sure how BFG is defined, if it has it's own entry or uses the BOW or GUN timings. If separate, might be worth checking too.

 

Otherwise, all the other weapons have the same timings for Pelting Strikes as for the base attack, so should be correct. Also, not sure if order matters here, but several of the entries for Pelting Strikes have a wrong timings order. No idea if it might cause something unexpected. Everything else is correctly ordered by timestamps. Example:

Spoiler

["entry8"] = 
        {
            ["name"] = "ANIM_TYPE_SM02_GUN",
            ["marker"] = 
            {
                ["ANIMSTART"] = 0.0000,
                ["SHOUT"] = 0.3600,
                ["ATTACK"] = 0.1600,

                ["ANIMEND"] = 0.9200,
            },

 

And when checking Frenzied Rampage, it is set correctly (only copies the base attacks) but I noticed a difference in timings for the base TGUN attack between vanilla and fixpack. All the other ranged weapon types have the same timings as vanilla. This is not a difference in Frenzied Rampage itself, but the actual base attack which Frenzied Rampage uses.

Vanilla TGUN:

Spoiler

["entry32"] = 
        {
            ["name"] = "ANIM_TYPE_ATTACKA_TGUN",
            ["marker"] = 
            {
                ["ANIMSTART"] = 0.0000,
                ["ATTACK"] = 0.2221,
                ["ANIMEND"] = 1.0000,
            },

 

PFP TGUN:

Spoiler

        ["entry32"] = 
        {
            ["name"] = "ANIM_TYPE_ATTACKA_TGUN",
            ["marker"] = 
            {
                ["ANIMSTART"] = 0.0000,
                ["SHOUT"] = 0.3600,
                ["ATTACK"] = 0.4000,
                ["ANIMEND"] = 1.0000,
            },

Same thing also for ANIM_TYPE_ATTACKB_TGUN (0.2665 vs 0.4000).

 

And one last animation related thing. As I was scanning over the various attack definitions, I noticed one difference in the Shadow Warrior attack timings. Specifically entry 38, 48 and 55 - ANIM_TYPE_ATTACKB_BH (just look at them in vanilla and the PFP).

In vanilla, it has 2 ATTACK occurrences on B, C and D while in PFP, it has only one, happening at a time exactly in the middle of the 2 attack timings. It seems like a double hit was occurring in vanilla on the 2nd, 3rd and 4th attack in the sequence for BH weapons (hafted weapons?), which has been removed. Although I have not tested this yet.

Who knows how many of these differences are there in total. Would it be worth to compare at least the attack animations and see if there are any further timing differences?

Edited by idbeholdME
Link to comment
2 hours ago, idbeholdME said:

Would it be worth to compare at least the attack animations and see if there are any further timing differences?

Please don't.  :3lmao:  There are going to be thousands of differences, and I'll drop dead of exhaustion trying to explain them all.

The shout timings coming later than the attack is a harmless mistake.

Most of the guns and tguns across all characters have later timings because the projectile would fire before the character could lift gun (firing into the ground).  The quicker animation blending speeds were doing most of the heavy lifting here but these also help match the firing with the animation.

  • Like! 1
Link to comment
9 hours ago, Flix said:

Please don't.  :3lmao:  There are going to be thousands of differences, and I'll drop dead of exhaustion trying to explain them all.

The shout timings coming later than the attack is a harmless mistake.

Most of the guns and tguns across all characters have later timings because the projectile would fire before the character could lift gun (firing into the ground).  The quicker animation blending speeds were doing most of the heavy lifting here but these also help match the firing with the animation.

Thought as much. Actually, as I was playing around with the original render.dll, the BFG fires the first projectile before it is fully aimed, confirming it brings back the original blending speed, shooting the first shot at an angle towards the ground when the CA is initiated while moving, due to the way she holds it while running (the end of the gun is above her). The second shot flies straight. With the PFP file, the first shot comes out only after she has already assumed the fully aimed position.

Anyway then, besides the bow timing for Pelting Strikes, the ranged behavior of the 2 CAs now is exactly as it is in vanilla.

Edited by idbeholdME
Link to comment

Played some more today. A couple notable things.

1) Gartor, the new turtle boss in the pirate cave seems to have an improperly set level. I was there at level 16 on Silver. All other enemies were the correct level, but Gartor was level 12.

2) Just tried Frenzied Rampage with a 1-handed staff and HOLY HELL!!! Shadow Warrior never had access to ranged staves, but as the PFP makes all staves ranged by default, it is incredibly overpowered with Frenzied Rampage. It uses the same animation as a Melee Frenzied rampage (which looks weird by itself), but it also launches probably more than 10 projectiles within a single Frenzied Rampage cast in a non-stop volley fashion, automatically retargets once the first target dies, and annihilates pretty much everything. Definitely needs to be tuned somehow. The best would honestly be if Shadow Warrior did not have access to ranged staves at all, to stay in line with vanilla. But I somehow doubt that giving Shadow Warrior an exception for the staff change would be an easy thing, if possible at all....

Temple Guardian is the only other class that does not have access to Staff Lore. Can he even use staves? I played him only once and very briefly a long time ago. If he can, it would probably be good to check out how ranged staves behave with his CAs.

So if possible, prevent SW and TG from being able to use ranged attacks with staves. Would be the best option IMO and in line with the vanilla. If not, then these two classes need to be thoroughly checked for how their non-single hit CAs behave with ranged staves as they never had access to that before and fix/tune it to reasonable levels. I pretty much never touched staves before, let alone ranged, so I have no idea how ranged staves behave with the CAs of classes that did have access to Staff Lore, but I doubt that they just use the same animation as they did for melee and spam projectiles non-stop.

3) The auto-pickup ignores the rule you select in the game options when it comes to items that are for a different class than you are currently playing. Playing a SW, It correctly picks up only blue and up for Shadow Warrior items, but still picks up all the garbage items for other classes. I think that has always been the case, but could make for another decent QoL improvement in the PFP.

Edited by idbeholdME
Link to comment
49 minutes ago, idbeholdME said:

Gartor, the new turtle boss in the pirate cave seems to have an improperly set level.

Creatures spawned through quest.txt have their levels set when the game session starts.  Gartor is essentially waiting for you as soon as the game starts so possible to outlevel him.  It's the same for other bosses not tied to quests such as Scaron or Forest Guardian.  One solution would be to tie them to a quest so that they only spawn when the quest updates at a certain stage, but inventing quests is not something I want to do in this mod.

 

52 minutes ago, idbeholdME said:

Just tried Frenzied Rampage with a 1-handed staff

I'll take a look tomorrow. Staff Lore does not control access to staves, that's controlled through itemtype.txt and/or blueprint.txt, and to an extent in the code.  So the Shadow Warrior could theoretically be restricted from using staves entirely if I made all staff blueprints off-limits.

An alternative would be to reduce the number of hits in animation.txt.  I think the animation is the original melee staff/polearm animation (5 hits) but the hits are doubled due to the way the CA somehow auto-adds the extra hits when projectiles are in play.  So I'm reasonably confident we can get it down to 5 hits like melee.

The TG should perform 4 hits I believe, same as melee.

As you figured out, both could always use staves but could never shoot staff projectiles until PFP, because without the skill staves used to just be melee weapons.  We changed staves to always-ranged to prevent a much more dire exploit: that of the Dryad (and Inquisitor to a lesser extent) being able to insta-hit everything on screen with Darting Assault and Ruthless Mutilation, respectively.  Scything Sweep would have also triggered this bug but of course the SW didn't have Staff Lore.

 

48 minutes ago, idbeholdME said:

The auto-pickup ignores the rule you select in the game options when it comes to items that are for a different class than you are currently playing.

Requires a code change. Only solution is currently in the Addendum.

  • Like! 1
Link to comment
17 hours ago, Flix said:

I'll take a look tomorrow. Staff Lore does not control access to staves, that's controlled through itemtype.txt and/or blueprint.txt, and to an extent in the code.  So the Shadow Warrior could theoretically be restricted from using staves entirely if I made all staff blueprints off-limits.

If it is impossible or would be too complicated to disable ranged staff attacks just for the Shadow Warrior and Temple Guardian, then completely restricting staves from the two may seem a bit harsh but SW and TG never had access to ranged staves and as that was made default in the PFP, the vanilla logic should be kept (IMO at least). With all the other classes, you would be taking the Staff Lore anyway if you wanted to make a Staff Build so it's not that big of a change for them to make staves ranged by default.

But then again, that will be denying the 2 classes access to useful Staff weapons, like Rancuil's Dark Flame (which literally just dropped for me 10 minutes ago :yay:) for buff casting and potentially tons of other items. As I doubt that anyone used staves as main weapons previously on SW and TG, probably just balancing the CAs could be a better approach. But who says when it's balanced? :/

But of course, if others have any input or ideas, let's hear them. I don't want to come off as some sort of the only authority on this :4rofl:

 

17 hours ago, Flix said:

Requires a code change. Only solution is currently in the Addendum.

Oh? Does something already exist to adjust auto-pickup behavior? I can't see an addendum section anywhere, could you please link? 

17 hours ago, Flix said:

Creatures spawned through quest.txt have their levels set when the game session starts.  Gartor is essentially waiting for you as soon as the game starts so possible to outlevel him.  It's the same for other bosses not tied to quests such as Scaron or Forest Guardian.  One solution would be to tie them to a quest so that they only spawn when the quest updates at a certain stage, but inventing quests is not something I want to do in this mod.

Gotcha. It's not really that big of a deal, just something I noticed and only really relevant in the very early levels.

 

EDIT:

Did some more testing with Frenzied Rampage, especially the mods and some very interesting findings. Testing with a bow.

1) Even though it launches only 2 projectiles visually, it deals 3 instances of damage. Happens both with and without the PFP activated. It is the second arrow that deals the damage twice. If only the first arrow misses, damage is dealt twice, if only the second arrow misses, damage is dealt once. If both hit, 3 hits.

2) The double hit mods that are supposed to only work with melee work with the ranged FR attacks. Tried both with and without the PFP. I took Double Hit, Double Hit, Life Leech and in both cases, managed to get 6 damage and Life Leech instances from a single FR attack after a couple of tries, proving both that the Double Hit mods work on it and that it is in fact 3 and not 2 attacks.

 

Really strange behavior TBH. Especially considering it behaves the same with or without the PFP, suggesting it's been this way for a long time. I even double checked on a completely fresh install and a brand new Shadow Warrior and that is how it's apparently always been. As the tooltips for FR in the PFP have been changed for the double hit mods (to specifically mention it only works with melee), they should probably be reverted back as they actually DO work on ranged weapons (bows at least). It might just be an internal quirk of Frenzied Rampage, as the wiki specifically says that Double Hits for ranged weapons are impossible at the code level. Not sure.

Edited by idbeholdME
Link to comment

During the MSQ in the Orc village Sloptok you're sent to the north gate to kill some of the invading enemy clan Orcs.
I am able to kill every Orc there, even the friendly one's are marked hostile.
They do not attack me and I can't damage them with Area of Effect but I can kill everyone with my Singletarget CAs.

Not a huge problem, it doesn't affect the quest success.

I didn't experience that before the Purist Fixpack.

Link to comment
9 hours ago, idbeholdME said:

Oh? Does something already exist to adjust auto-pickup behavior? I can't see an addendum section anywhere, could you please link? 

Sorry, by Addendum I mean Dmitriy's Mod.  Similar to Enhanced Edition, though much more extensive.  "Addendum" is really a very modest title for a mod that transforms the game completely. It also happens to be the only place where further hard-coded bugs are being addressed past CM 1.60, because D's the only modder I know of that can do that.  I think he's reading the raw Assembly code with Ollydbg.

9 hours ago, Vishanka said:

During the MSQ in the Orc village Sloptok you're sent to the north gate to kill some of the invading enemy clan Orcs.

I'll check it out, thanks.

  • Like! 1
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...
Please Sign In or Sign Up