Jump to content

Sacred 2 Downloads - DIMITRIUS'S CM PATCH ADDENDUM - 2023


Recommended Posts

3 hours ago, Flix said:

In at least one instance you've given equipment to enemies that should not have it

Thank you, I've updated the archive and the hotfix. Never changed this one, though. The erroneous assignment is present in CM Patch 1.60, as well as previous CM Patch iterations and the original creatures.txt(29.07.2009). It's a vanilla oversight Should be an isolated case.

Edited by dimitrius154
Link to comment

I found another odd item with Sinister Adroitness Aspect Combat Arts +1 in blue when it should be in red since I was playing as a Dragon Mage. I'm uploading my savefile with the amulet in case this helps.

hero61.sacred2save

Edit: This amulet was given as a quest reward. The quest was called Sickle Moon Wool or something like that.

Edited by mewkang
  • Like! 1
Link to comment
7 hours ago, mewkang said:

Sinister Adroitness Aspect Combat Arts +1 in blue when it should be in red since I was playing as a Dragon Mage

Interesting - a vanilla oversight. So the Dragon Mage Aspect CA bonus item modifiers were always being displayed in red(unavailable) for the Dragon Mage, while the Shadow Warrior Aspect CA bonus item modifiers were being displayed in blue(available). Wonder, why no one had ever noticed before. Updated the archive and the hotfix.

Edited by dimitrius154
  • Thanks! 1
Link to comment

A few notes on your spells.txt:

    fxTypeCast = "FX_DM_VERTRAUTER_C",
    fxTypeSpell = "FX_DM_VERTRAUER",

Wasn't there a missing "T" in the second line that was preventing the summoning fx?  I'm showing "VERTRAUTER" in my own mods that I built off of 1.60.

 

I see "et_duration_sec" added to a few enemy spells (and one or two hero CA's).  I assume this is to prevent various debuffs to speed, attack values, etc. from being permanent until reload?  I ran into this in D2F but never noticed there were vanilla spells with this problem.

 

"boss_flyer_tball" has fxTypeSpell = "fx_fd_tschuss_L", in vanilla, fxTypeSpell = "fx_fd_tschuss_R", in Addendum.  What's going on there?

 

Should the spell "boss_flyer_aufladen" only be assigned to the "Boss_ju_energystation" traps, and not the boss itself?

Link to comment
6 hours ago, Flix said:

Wasn't there a missing "T" in the second line that was preventing the summoning fx?

I've changed the appellation in the code. It's "VERTRAUTER" in the Addendum.[EDIT] False, it's "VERTRAUER":blowup:

 

6 hours ago, Flix said:

I assume this is to prevent various debuffs to speed, attack values, etc. from being permanent until reload? 

Yes, that as well. Also, the entry supplies a certain minimum debuff duration.

 

6 hours ago, Flix said:

"boss_flyer_tball" has fxTypeSpell = "fx_fd_tschuss_L", in vanilla, fxTypeSpell = "fx_fd_tschuss_R", in Addendum.  What's going on there?

It's a dual plasma discharge. The spell was completely broken in vanilla. That's why Khral was showing a shooting animation from time to time, but nothing happened.

 

6 hours ago, Flix said:

Should the spell "boss_flyer_aufladen" only be assigned to the "Boss_ju_energystation" traps, and not the boss itself?

Actually, recharge towers are firing at Khral, not the reverse.  

Edited by dimitrius154
Link to comment

Thanks for the answers.  It's astounding how badly the bosses were implemented in vanilla, considering they are such major opponents.

 

Although I was letting your know that the Addendum spells.txt I downloaded a few weeks ago still reads:

fxTypeSpell = "FX_DM_VERTRAUER",

So if I followed you correctly, you'd want to add the "T".

Link to comment
2 hours ago, Flix said:

how badly the bosses were implemented in vanilla, considering they are such major opponents.

Not only them, some minibosses, while assigned spells, were technically missing the needed animation entries. That results in them just standing from time to time.

2 hours ago, Flix said:

fxTypeSpell = "FX_DM_VERTRAUER",

So if I followed you correctly, you'd want to add the "T".

I've corrected my previous post. It's still "VERTRAUER" for fxTypeSpell - adds a sandy whirl while the summon is spawned. 

Link to comment

Another small spells.txt note - some spells are using "skill_enemy_focus" for both the focus and lore skills (vanilla bug):

"boss_fog_leuchtkugeln"

"Boss_BM_master_Schockwelle"

  • Like! 1
Link to comment
On 8/8/2018 at 0:11 AM, dimitrius154 said:

Should be an isolated case.

I think there's at least one other.  Elven Ghosts are now spawning with the (non-ghostly) chest and head armor of normal elf robbers (equipset_id = 125).

5b7a0f5d535ae_sacred22018-08-1919-39-04-52.thumb.jpg.6d1e3899207d88240c080a520151c3ea.jpg

Itemtype 6823, creatures 415 and 2151.  I think the solution here is to remove the equipsets from the creature entries.

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

Itemtype 6823, creatures 415 and 2151.  I think the solution here is to remove the equipsets from the creature entries.

Thank you, I've updated the archive and the hotfix.

Both this and the fleshhound case(as well as some others, potentially) can actually be considered vanilla oversights, unnoticed back then, because they kind off "fixed" erroneous equipset assignment in creatures.txt with missing equipment slot subentries in creatureinfo.txt.

I'd have to rely on others reporting such occurrences, since they can only be detected by extensive gameplay, something I don't quite have enough time for now. 

  • Like! 1
Link to comment
7 hours ago, dimitrius154 said:

Both this and the fleshhound case(as well as some others, potentially) can actually be considered vanilla oversights, unnoticed back then, because they kind off "fixed" erroneous equipset assignment in creatures.txt with missing equipment slot subentries in creatureinfo.txt.

Correct.  The bug was unnoticed because of another bug.  :)

 

7 hours ago, dimitrius154 said:

I'd have to rely on others reporting such occurrences, since they can only be detected by extensive gameplay, something I don't quite have enough time for now. 

That's why I'm making these posts.  I'm working on porting such fixes to my mods and despite it being a lugubrious process, I wanted to check each one.

  • Like! 1
Link to comment

More weirdness.  Orc Clan Leaders now have their banners (shoulder armor) but also are equipped with weapons that they can't use (axes buried in the ground at their feet).

Offending equipsets:

equipset_id = 449,

equipset_id = 450,

These equipsets are assigned only to the taskcreatures in quest.txt, and since no other creatures use these equipsets I'm just going to remove the axe from the equipsets.

Link to comment
16 hours ago, Flix said:

I'm just going to remove the axe from the equipsets.

It might be a better idea to displace the v_ork-offizier-v1@leader.GR2 with v_ork-offizier-v1@std.GR2 in itemtype.txt:

 

newItemType = {
	-- standard info
	renderfamily = "RENDERFAM_CREATURE",
	renderprio   = 0,
	family       = "FAMILY_CREATURE",
	subfamily    = "SUBFAM_LIFE_ORC",
	classification = "CLF_DEFAULT",
	flags        = "FLAG_HASPREVIEWIMAGE",
	weargroup    = "WEARGROUP_NPC_ONLY",
	-- 3d model + animation info
	model0Data = {
	  name         = "models/npc/monsters/orc-officer/v_ork-offizier-v1@leader.GR2",
	  user         = "WEARGROUP_INVALID",
	},
	-- logic bounding box
  logicBox = {
    minx=-22.804, miny=-13.077, minz=-0.799, 
    maxx=19.67, maxy=19.552, maxz=69.497, 
	},
	dangerclass   = 0,
}
mgr.typeCreate(9269, newItemType);

newItemType = {
	-- standard info
	renderfamily = "RENDERFAM_CREATURE",
	renderprio   = 0,
	family       = "FAMILY_CREATURE",
	subfamily    = "SUBFAM_LIFE_ORC",
	classification = "CLF_DEFAULT",
	flags        = "FLAG_HASPREVIEWIMAGE",
	weargroup    = "WEARGROUP_NPC_ONLY",
	-- 3d model + animation info
	model0Data = {
	  name         = "models/npc/monsters/orc-officer/v_ork-offizier-v1@leader.GR2",
	  surface0     = { mgr.surfGetID ("ork-leader-v1-id1_v"), mgr.surfGetID ("ork-leader-v1-c3-id1_v") },
	  surface1     = { mgr.surfGetID ("ork-leader-v1-id2_v"), mgr.surfGetID ("ork-leader-v1-c3-id2_v") },
	  surface2     = { mgr.surfGetID ("ork-leader-v1-id3_v"), mgr.surfGetID ("ork-leader-v1-c3-id3_v") },
	  user         = "WEARGROUP_INVALID",
	},
	-- logic bounding box
  logicBox = {
    minx=-22.804, miny=-13.077, minz=-0.799, 
    maxx=19.67, maxy=19.552, maxz=69.497, 
	},
	dangerclass   = 0,
}
mgr.typeCreate(9270, newItemType);

to

newItemType = {
	-- standard info
	renderfamily = "RENDERFAM_CREATURE",
	renderprio   = 0,
	family       = "FAMILY_CREATURE",
	subfamily    = "SUBFAM_LIFE_ORC",
	classification = "CLF_DEFAULT",
	flags        = "FLAG_HASPREVIEWIMAGE",
	weargroup    = "WEARGROUP_NPC_ONLY",
	-- 3d model + animation info
	model0Data = {
	  name         = "models/npc/monsters/orc-officer/v_ork-offizier-v1@std.GR2",
	  surface0     = { mgr.surfGetID ("ork-offizier-v1-id1_v"), mgr.surfGetID ("ork-leader-v1-id1_v") },
	  surface1     = { mgr.surfGetID ("ork-offizier-v1-id2_v"), mgr.surfGetID ("ork-leader-v1-id2_v") },
	  surface2     = { mgr.surfGetID ("ork-offizier-v1-id3_v"), mgr.surfGetID ("ork-leader-v1-id3_v") },
	  user         = "WEARGROUP_INVALID",
	},
	-- logic bounding box
  logicBox = {
    minx=-22.804, miny=-13.077, minz=-0.799, 
    maxx=19.67, maxy=19.552, maxz=69.497, 
	},
	dangerclass   = 0,
}
mgr.typeCreate(9269, newItemType);

newItemType = {
	-- standard info
	renderfamily = "RENDERFAM_CREATURE",
	renderprio   = 0,
	family       = "FAMILY_CREATURE",
	subfamily    = "SUBFAM_LIFE_ORC",
	classification = "CLF_DEFAULT",
	flags        = "FLAG_HASPREVIEWIMAGE",
	weargroup    = "WEARGROUP_NPC_ONLY",
	-- 3d model + animation info
	model0Data = {
	  name         = "models/npc/monsters/orc-officer/v_ork-offizier-v1@std.GR2",
	  surface0     = { mgr.surfGetID ("ork-offizier-v1-id1_v"), mgr.surfGetID ("ork-leader-v1-c3-id1_v") },
	  surface1     = { mgr.surfGetID ("ork-offizier-v1-id2_v"), mgr.surfGetID ("ork-leader-v1-c3-id2_v") },
	  surface2     = { mgr.surfGetID ("ork-offizier-v1-id3_v"), mgr.surfGetID ("ork-leader-v1-c3-id3_v") },
	  user         = "WEARGROUP_INVALID",
	},
	-- logic bounding box
  logicBox = {
    minx=-22.804, miny=-13.077, minz=-0.799, 
    maxx=19.67, maxy=19.552, maxz=69.497, 
	},
	dangerclass   = 0,
}
mgr.typeCreate(9270, newItemType);

 

The "leader" model is, in fact, sort of an inferior variant of the "std" model - no shield, or weapon bones. Could be an oversight.

[EDIT] Yes, replacing entries in itemtype.txt is a better option. Updated the main archive and the hotfix.

Edited by dimitrius154
  • Like! 1
Link to comment

Dmitriy, I need your advice on something.  I've had enough feedback on GOG and other game forums about how the Community Patch is avoided by numerous players due to overstepping the boundary between patch/mod, which leads me to want to try making a simplified, fix-only version.

It's easy enough for me to do all the work that doesn't involve the binaries.  But just providing stock CM 1.60 binaries has its own issues.  There are 10 important fixes that currently only exist in your mod, and AFAIK can ONLY exist in this mod.

What I wanted to ask is which binaries (if any) are responsible for each of the 10 changes below?  As I understand it, anything requiring extra space in s2logic.dll would be off the table for the project, as purists would never go for the mount purification.

1. One of the primary calculation functions, used in attack vs. defense, spell intensity vs. spell resistance, damage vs. armor calculations has been fixed.
    Probably one of the most important fixes.
2. "Combat Art Skills +" modifier behaves correctly now, improving "Spellcraft Lore", "Combat Discipline" and "Concentration" skill instead of "Shield Lore" and "Warding Energy Lore".
    Another one that boggles the mind on how this wasn't fixed before release.
3. Non-player aligned NPC damage is mitigated by 85%. Escort quests should no longer be the same potion spamming frustration, as before.
    You must have done something in the code to prevent pets from being affected by NPC damage downscaling in balance.txt?
4. Item classification character-specific modifiers should now spawn correctly.
    Not sure I understand where this change is happening at all, but no changes in the scripts seemed to reflect it?
5. Rings, amulets, other forgeables are now affected by item auto-collect quality filter settings in the "Gameplay" menu.
6. Boss and miniboss AI discrepancies and faulty CAs have been corrected. Occurrences of bosses stopping in their tracks, or wandering aimlessly during combat should no longer happen.

    Most of this seems to have been done outside the binaries, with one notable exception being the fix for "boss_flyer_tball".
7. PhysX object behavior in the game world has been optimized.
    
I noticed physx.zip is completely repackaged in the Addendum.  Are any other files contributing to this fix?
8. Occurrences, where, upon changing locations via doors, or secondary teleports, various objects and NPC states at the new location were not updated in a timely manner, should no longer manifest.


9. It is now possible to traverse dungeons levels and enter-exit dungeons without dismounting. Previous technical limit have been successfully alleviated.
    
I only include this one because it's currently half-assed in stock CM 1.60.  Restoring to vanilla (no mounts underground) would also work for the project. 
10. The Dragon Mage does no longer lose his active buffs during Berserk Form, or Dragon Form transformations. However, he can no longer manage his buffs(switch them on/off), while transformed.
    
Again, it's half-assed in 1.60, allowing buff stacking exploit when changing back to human form. Vanilla functionality would also suffice, given the aim of the project.

 

I'm just trying to get an idea of what's possible here.

  • Like! 1
Link to comment

I don't see how anyone wouldn't want to use the CM patch. Game stability alone is reason enough in my book to use it. The mod that keeps the annoying temporary allies from dying so quickly (unless you spam health potions) is greatly appreciated. And all the restored content is great as well. There is no way I would ever play the game again without the CM patch.  That being said, I won't use the Addendum due to a couple of changes: pre-selected deities and having to beat an Ice & Blood endgame boss before you can get an elite mount. 

I like being able to pick which deity a toon uses (except the Seraphim & Inquisitor of course), and having to  wade through the entire Blood Wood  or Crystal Forest before I can have an elite mount, is a bit much. If those two changes can be made optional, then I would be happy to give the Addendum a whirl..

 

 

Link to comment
23 minutes ago, CapnTucker said:

I like being able to pick which deity a toon uses

"preselected" means "default": the one selected, when you click a char icon in the char selection screen. You can still choose deities.

 

23 minutes ago, CapnTucker said:

having to  wade through the entire Blood Wood  or Crystal Forest before I can have an elite mount

In stock CM Patch you have to search for elite mount trader - it isn't exactly easy, if you don't know where to look. The reason is the same - once elite mounts are available, class mounts are made obsolete, just as horses are made obsolete, once class mounts are available. Not much sense in making class and elite mounts available at the same time.

Edited by dimitrius154
Link to comment

We always meant to have a gate-keeping quest for elite mounts - this is easier than scripting a new one.  Though they don't necessarily make regular class mounts obsolete.  Most of them just have one extra modifier, usually locked by the Riding skill.

 

My main objection to the Addendum is what's presented as fixes - namely all the liberties taken with game texts and combat arts.  Rewriting quests, using new aspect artwork, renaming multiple modifiers, spells, and skills, and changing the mechanics of how several combat arts work and the aspect skills tied to them.  It's not that they necessarily make for a bad gaming experience (I wouldn't go on Llama's Mod and object to his changes), it's just that they're presented as fixes and corrections, when they're really just subjective mod content.

Link to comment

Good to know that the deity is still optional. Regarding the elite mounts, yes I know it takes a while just to reach the isle of mounts.  Instead of having to trudge off for a long slog through the entire Blood Wood, make it so that any area big boss will do for the final challenge (except the Kobold Chief; he's pretty weak). For example, the Gar Colossus could be an acceptable last obstacle to getting your elite mount..

 

 

Link to comment
  • The topic was unpinned
  • The topic was pinned
1 hour ago, CapnTucker said:

Gar Colossus could be an acceptable last obstacle to getting your elite mount..

It's not about difficulty really, it's about the interval between gaining access to class mounts via a quest in Urthak's Moxie(right before the Gar'Colossus, by the way) and gaining access to elite mounts. It has to be a long one.

 

6 hours ago, Flix said:

changing the mechanics of how several combat arts work

This is reserved for the optional Dark Side mod, I believe. The Addendum CAs don't veer away from original.

 

6 hours ago, Flix said:

what's presented as fixes - namely all the liberties taken with game texts and combat arts.  Rewriting quests, using new aspect artwork, renaming multiple modifiers, spells, and skills

That has never been presented as fixes, rather as improvements. I've never tried to hide the subjective nature of those changes, as proven by my answer to a direct question from Androdion.

Renaming certain item modifiers was a logical thing to do, since their original naming was plain confusing. "Opponent Level for Deathblow" is a prime example.

Original class quest texts for the Inquisitor were somewhat weak, and the Shadow Warrior class quest progression story was non-existent.

Link to comment
Quote

1. Incorrect "Tactics Lore" skill dependency for several combat arts has ben corrected. "Dust Devil", "Killing Spree", "T-Energy Shroud", "Deathly Spears" now depend on "Spellcraft Lore".
2. "Spectral Hand", "Archangel's Wrath" and "Magic Coup" now depend on "Tactics Lore", due to them being weapon-based CAs.

The vanilla aspect lore assignments were not incorrect.  Each aspect got a focus and lore skill, that was logical consistency, even if spells got boosted from Tactics Lore or Archangel's Wrath got boosted by an aspect lore, it kept the aspects consistent.  Everyone understood it, everyone knew what to expect.  All the documentation and game guides accounted for this.

Certain modifiers, yes.  Combat arts, skills, and entire aspects?

I have a lot of respect for you dividing the project into two parts, one for patch content, one for mod content.  But the line between the two is drawn in a strange place, and IMO a lot of mod content has spilled over.

Link to comment
  • The title was changed to DIMITRIUS'S CM PATCH ADDENDUM - 2023
  • This topic was featured and unfeatured
  • The topic was featured

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