Mike1072

My guess about wands was based on finding these files during a quick search of the repo.  Are they not being used?

On 1/25/2020 at 11:19 AM, subtledoctor said:

Worst comes to worst, you can just put the English line into the Russion .tra file, so at least it will work and Russian speakers will have a slight little bit that is not translated.

I'm way late here, but you can accomplish the same thing by loading the English .tra file before the Russian one.  References that exist in the Russian .tra file will appear in Russian while those that don't exist will appear in English.

Here's an example from IR's .tp2 file:

Edit: Actually, here's an example from RealMod's .tp2 file, which contains this info along HANDLE_CHARSETS integration and other good tips:

AUTO_TRA ~real_mod/languages/%s~ //~%~

LANGUAGE
  ~English~ // Name as displayed in WeiDU's language menu
  ~english~ // Name of folder actually containing tra files.
  ~real_mod/languages/english/real_mod.tra~ // tra file containing game content strings.
  ~real_mod/languages/english/setup.tra~    // tra file containing only strings for WeiDU's install process. 
  
/* 
If you have more than one language, use the block below as a template. 

Note the English tra files listed above the translated ones. This allows languages with partial 
translations to still be installed, but with English in place of missing strings.

LANGUAGE
  ~Francais (Translation by someone)~
  ~french~
  ~real_mod/languages/english/real_mod.tra~
  ~real_mod/languages/english/setup.tra~
  ~real_mod/languages/french/real_mod.tra~
  ~real_mod/languages/french/setup.tra~
*/

7 hours ago, subtledoctor said:

Yes but I did not say other components need to go after FnP.  I only stressed that IR's main component definitely needs to be installed first.  I have no information about the other IR components... they probably can also be installed earlier; there is only not particular reason (that I'm aware of) why they must be.

In general, if a mod adds weapons, armors, shields, helmets, bracers, or wands, then IR's global components should be installed after it.

I think FnP has wands at least.  However, IR would need to be updated to support the specific items.  (The same goes for armors, shields, and bracers.)

I used WinMerge to generate this list of files that were changed between 1.6 and 1.7:

• english/English.tra
• !scombus.spl
• !sdrainr.spl
• !sforce.spl
• !spcnec.spl
• !stun.eff (added)

3 hours ago, Lauriel said:

You've been able to successfully use a strref in TokenTxt.2da?

No, I don't have any first-hand knowledge of this.  Just making a joke.  It sounds like you found an error in the IESDP.

I do what the docs tell me to.

You can add a string to the game and store its assigned strref in a variable using SET blahblah_strref = RESOLVE_STR_REF (~blahblah~).  It should work with tra references too: SET translated_strref = RESOLVE_STR_REF (@123).

Then you can use that variable when you are adding to the .2da.

Ah, glad to hear it wasn't more serious.  Thanks for the update.

4 hours ago, DavidW said:

That icon is just the generic Identify icon (spwi110c.bam), it's not anything specific to SCS.

Yeah, but it looks out of place in the screenshot - shouldn't it be spwi110b.bam?

Because ToBex (which is included in IR) changes the engine to let us enable backstabs with ranged weapons.

However, ToBex works with the classic games only (BG2: ToB, BGT, EasyTutu_ToB) — not the EE games.

21 hours ago, Azazello said:

Separate issue, not cosmetic, may been reported elsewhere, point me to the link if it has--- when did some threads start getting Archived?? That was not a thing in the past.

e.g. Conflict with cleric and druid HLA tables from Refinements - Divine Remix - The Gibberlings Three

What's the policy about when that happens?

I'm not sure.  This is the first instance I've seen.  It may have happened a really long time ago during one of our hosting moves.  I know there is an option available to admins to archive posts older than a certain date, but I don't think we've ever used it.  I think archiving posts prevents them appearing in searches, which I don't like.

Moderators have a separate tool available called locking and unlocking topics that we can use if we want intentionally prevent further replies.

21 hours ago, Azazello said:

Can moderators UnArchive threads?

Yes, we can.

Edit/Update: Turns out that the new forum update got rid of the manual archiving feature that existed previously, and replaced it with an automated one that archives tons of old topics.  Hooray!  I've put in a support request to see what they can do about that.  I loathe when updates make the experience worse.

It was just how the engine worked - it applied backstabs when attacking with melee weapons usable by single-class thiefs.  ToBex included the ability to change that behaviour.

I don't know if an equivalent feature was added to the EE games or might be added by EEex.

2 hours ago, Bartimaeus said:

The description of the subcomponents in the readme merely says the first option will enable variable backstab penalties for weapons usable by pure thieves, while the second component says it'll additionally enable backstabbing for some other types of non-thief weapons (not perfectly clear on which ones) but apply the listed penalties, while the third option will enable backstabbing for *all* weapons (including ranged ones) but apply the penalties to them.

Apologies, the description could be clearer.

In the vanilla game, weapons are either capable of backstabbing or incapable of backstabbing.  All weapons capable of backstabbing do so using the same multiplier.  The engine decides which weapons are capable of backstabbing by checking if they are usable by single-class thieves.

The idea behind Revised Backstabbing is that this binary system doesn't make much sense.  Shouldn't daggers be better at backstabbing than quarterstaffs?

• The 1st subcomponent applies backstabbing penalties for less-suitable weapons, but does not enable backstabbing with weapons that could not backstab previously.
• The 2nd subcomponent applies backstabbing penalties for less-suitable weapons, and enables backstabbing with melee weapons that could not backstab previously.
• The 3rd subcomponent applies backstabbing penalties for less-suitable weapons, and enables backstabbing with melee and ranged weapons that could not backstab previously.

The backstabbing penalties for ranged weapons don't appear to be listed in the table (that subcomponent was added much later), but they are as follows:

• Darts, Light Crossbow: -1 Backstab Multiplier
• Heavy Crossbow, Short Bow: -2 Backstab Multiplier
• Sling, Long Bow, Composite Long Bow: -3 Backstab Multiplier

5 hours ago, Daeros_Trollkiller said:

I am also considering some changes to how the SoD items are obtained.   I've received plenty of feedback asking for specific SoD items to be added and to avoid over-saturation of adding more items, I am considering making some of them random.  For example:  You kill the monster that currently drops Element's Fury +2, after the change it would be a 50% chance of obtaining either element's fury +2 or acid-etched dagger +2.  You could get one or the other, but not both.

I am a big fan of that type of thing to make each play-through different, though some probably don't care for it.   So, if I do decide to go that route, it will likely be limited to only a few items.

You could make that an optional component.

That's the same approach I would take and it should work fine for the most part.

You might have to do a manual check to make sure there are no weapons in those categories that are restricted to those specific classes.  (For a contrived example, imagine if you had some code that gave druids access to all the weapons that paladins can use.  They would gain access to regular 2-handed swords that everyone gets but they would also end up being able to use Carsomyr.)  Your first set of patches has the potential to do a similar thing if there are any thief-only or fighter-only short swords, clubs, or crossbows in the game.  I don't know if there are any in vanilla but there are a lot of mods out there.  The easiest way to handle the oddities is to track them down and specifically exclude them from the patch.

P.S. I think fighter/thieves and fighter/mage/thieves are already able to use all those weapon types.

4 hours ago, NdranC said:

Looking at the code of IR(R) I have a couple questions on how it functions. Seems to me that the main component will just replace almost every item in the game with a custom version that is stored in the "itm" folder. Once that is done the other components will patch all items (including vanilla, IR and other mod items) in an attempt to customize them based on the .ini file and the other files with custom values like armor/weapons.

Assuming all of that is true. Is the identify_item.tpa not good enough for armors and shields? I've noticed there is some code attempting to classify armor but is there no reliable data point in game that tells you what armor or shield is supposed to be without a user submitted list?

Speaking of identify_item.tpa, specifically for weapons. Is using the proficiency offset with some help of strength requirement not enough for all weapons? I've noticed there is a lot of animation checking, maybe something else, I can't look at the moment.

I ask because I'm currently making my own mod to change some of the weapon proficiencies and part of that is adding quarterstaves to monks and short/long bows to druids. The way I'm currently doing it is checking all items that have the right proficiency and are also usable by thieves (in the case of quarterstaves) and fighters (in the case of druids). Looking at the IR(R) identify_item.tpa makes me feel this game is filled with contradictions at every step.

You have the right idea.  Armors are all over the map and manual identification is required.  Weapon detection is a lot easier to automate.  The fields you have to check depend on the specific category of item you want to identify.  Some can be done with just item type or item type and proficiency.  As a general rule, I'd recommend against trusting usabilities to determine weapon type (there are class-specific items that can easily be misidentified).  But they can work if you're doing more of a global change, like IR does with restricting fighter/druids to the same armor options as regular druids (code here).

@Endarire My priority with SR is general maintenance: resolving bugs and compatibility issues.  If the community agrees on some new content or design changes, and they code it up, I can incorporate it, but I won't be doing that myself.  (And you wouldn't want me to.  Design is not my strong suit.)

Your best bet for now would be to direct those sorts of ideas to @Bartimaeus for SRR or wait and see if @kreso or @Demivrgvs come back some day.

1 hour ago, pochesun said:

Also i wanted to ask you about item importing system. I personally prefer when i dont need to worry what i should bring from BG1 to BG2 and from SoD to BG2. IR solves the issue with BG1 items by allocating them throughout the BG2 game. But what about SoD items? If SoD items are not automatically allocated by IR in BG2 can i suggest to include those in BG2 the same way IR does it with BG1 items? Basically i suggest to auto include all SoD items available for import in BG2.

SoD to BG2EE Item Upgrade may be exactly what you're looking for.

3 hours ago, Bartimaeus said:

Though the .eff (brac11) casting the spell targets "self", the effects of the .spl itself do not, and instead do pre-target (2). I don't know enough about the set effect opcodes (248 and 249) to know how they're supposed to work, but I suppose the .spl doesn't carry over the targeting of the .eff and instead pre-target defaults to the attacked target. Simple fix by just setting each effect to self-targeting. Haven't used these bracers too much, guess I never noticed, haha. Tested...and that fixed it.

Thanks, that seems to have done it.  It gets a little complicated when there are 4 different places defining the target.  I'll include the other changes as well.

On 1/31/2019 at 1:23 PM, Lianos said:

Bracers of Speed
When the 5% fatigue effect triggers, the character performs an animation like he is casting a spell. This is annoying, as he stops attacking.

On 1/31/2019 at 7:53 PM, Bartimaeus said:

Bracers of Speed: brac11.eff needs to be set to type 1 instead of type 0, already fixed in IRR.

On 8/4/2020 at 3:03 PM, Lianos said:

Feedback to some of subtledoctors patches:

• Bracers of Speed - still an anmiation when triggered, and no fatigue effect anmyore - I think this was not intended?

I've been reviewing subtledoctor's patches for inclusion and can confirm that his patch still has the animation issue, while it's been resolved in IRR.

However, there seems to be a bigger problem here.  I did some testing on BG:EE and all of the different implementations are applying the fatigue effects to the creature being hit rather than the wielder.  I even did a little digging and tested out subtledoctor's suggestions from this other topic and experienced the same result.

@subtledoctor & @Bartimaeus, are you seeing the same thing?  (I recommend adjusting the probability chance in the .eff before testing.)

Thanks for the report.  If you have a choice of browsers, does it show up the same on all of them?

Anyone else experiencing the same issue? 

I think they messed up and released this version of the software early.  They have since released 2 patches and it's now labelled as a beta version.  And things keep breaking... now it's the background and the website.

Your patience is appreciated while this is sorted out.

There's no connection between the G3 and SHS hosting any longer.

The software updates come about once a month and usually take less than 5 minutes, so if you see that message, just check back a little later.

7 hours ago, Jarno Mikkola said:

Have you guys had these a lot ?

[img=https://i.ibb.co/8DjKkNH/Sieppa2a.jpg]

Cause I kinda have. And why does the preview show the image, but the final post does NOT !

A lot?  That message should only show up while the forum software is being updated, which is something the admins trigger.

There was one big update that prompted this topic (10-15 minutes) and then a small one (1 minute) yesterday.

I'm not sure what's going on if you're seeing them more often.  I've never experienced them outside of the updates.

On 8/21/2020 at 4:30 AM, argent77 said:

I noticed something weird (not sure if added by the recent update). The forum editor automatically replaces "x" by a multiplication sign when placed between two digits (whitespace is ignored), e.g. when used by hexadecimal notation for numbers. Can this kind of "autocorrection" be turned off somewhere?

Examples: 0x123, 0xx123, 0 x 123, 0 xx 123

On 8/21/2020 at 2:47 PM, Mike1072 said:

Eww, I hope so.  I'll investigate.

Edit:

@argent77 It turns out this is simply a display issue and is actually caused by the font (Inter).  I'll think about whether it's a big enough issue to justify swapping to a different font.

I swapped out the font.

See here.  You define the array before the COPY action.