hey Lance,
yeh it’s a rabbit hole … unfortunately i’m conserving energy for other things … else i’d study it and be able to help out with specific issues
feel free to keep posting any interesting findings, and askin’ advice ofc.
Hi KevL,
Sure, no problems, I understand what you mean about needing to conserve energy for other things. 
I did just add/edit this point as my latest info …
EDIT: OK, so this function led to InitializeCreatureInformationInternal and I don’t really understand what that is doing with some of the coding there. (e.g. |= Don’t know what this means.) So, now I am going to try to play test with the DOMINATE effect on SUMMONED, which appears to be the only relevant issue by the looks of it. Although, in my module if a summoner is “killed”, the summoned is un-summoned, so the second bug issue mentioned below is likely irrelevant … but I’ll try testing anyway.
I’ll report back after some more testing.
Thanks, Lance.
InitializeCreatureInformation() leads into the core ai scripting. It makes extensive use of bitwise variables
|= is bitwise “add the values and assign the result to the first value” (a bit of google-fu can find lots of tutes about bitwise operations, if you’re really interested)
It looks like the state scripts are merely summing up a critter’s current positive and negative effects (etc.) for use by the AI in case another AI-controlled creature wants to target it during a DCR round.
1 Like
Hi KevL,
I find I struggle getting my head around bitwise stuff. I think I understand it and then I lose myself somewhere in my thinking. However, as it is not really doing much towards “faction” related stuff, I will ignore it as irrelevant to any possible issue we are trying to find …
At the moment, simply trying to play-test a scene where my enemy dominates a summoned is not as straightforward either. I am hoping to see the issue first hand and then implement a faction/party rejoin fix if required (via Greater restoration spell script).
If that works, then we only need to rewrite GetScaledEffect to cater for game difficulty as we see fit and correct the tlk entries. i.e. If DOMINATE effect is not the huge problem it appears to be, then I will likely only change for DAZED on easy setting anyway.
For example, when I was play testing my crew against a vampire who used its gaze, a companion was “Dominated”, and there was no issue from that perspective. i.e. Fellow companions. So, just to check this summoned creature etal position.
Thanks, Lance.
All tests were carried out bypassing the GetScaledEffect function to ensure the original effect was passed.
FIRST TEST …
Sent summoned shadow beast into combat v vampires … When dominated, it left party, but died (and unsummoned) before I could do anything else. 
JUST REALIZED SOMETHING …
I may have a more difficult time testing this as my own summoning code changes the default scripts of the summoned creatures subject to whether the creature was summoned by the party or an NPC anyway! It could well be that my own scripts circumvent the issue anyway, as they are swapped for “gb_assoc_XXXX” types (with a few alterations). Hmmm.
SECOND TEST … (Bearing in mind it uses my scripts) …
After ensuring the summoned does not die too quickly … When dominated, the summoned is removed from the party bar, but (currently) remains friend to party and continues to attack the enemy. However, when the enemy is killed (by me), it unsummons … as if its “new master” had been killed. This suggests the summoned did acquire a new master, but did not swap to its new master’s faction. (I may now try adding some code to the NW_G0_Dominate script to ensure the summoned switches allegiance so I can test the Greater Restoration.)
THIRD TEST (JUST CHECKING) …
As far as I can see … Using DOMINATE on companions does nothing to change status between party and/or enemy. Apart from the fact that they cannot move, an enemy will continue attacking them. Furthermore, if the dominated is attacked/damaged, the domination ends. Therefore, I (currently) don’t see a problem with the dominated effect on companions, as all it does is stop them from attacking the enemy … Furthermore, I now suspect that NW_G0_dominate does NOT fire when a PC is DOMINATED (which the name NPCDominate in statescripts would also imply) as debug script does not return any feedback when the DOMINATE effect is used against a companion. I also just checked to see if I received debug feedback when trying to dominate a summoned, and it appears the NW_G0_dominate does NOT fire for dominated party summoned creatures either. I am going to try to make that script fire by trying to dominate an NPC now. … When I cast Dominate Person on a “hostile” NPC (villager turned enemy to party if they failed their saving throw), they became a member of the party (like a henchman who you cannot control). BUT, the NW_G0_dominate script still does NOT fire as far as I can tell. Also, (interesting I thought), having an NPC added as a henchman did not cause the usual crash when exiting like normal henchmen do, even though the code I have in place did not remove it like other henchmen. Therefore, there is definitely something different about dominated party members to normal party members with respect to this point. When the domination ends, the NPC leaves the party and returns to being an enemy.
FOURTH TEST …
Editing nw_g0_charm does show it fires after charming an NPC or PC. It fires every heartbeat the charm is in place on the NPC. NOTE: A charmed NPC does NOT join the party like a DOMINATED NPC does. Checking PC … OK, the EffectCharmed is quite interesting when cast on a PC … This is (in some ways) quite an effective effect as it not only stops a PC from attacking, but it also stops the enemy from attacking the PC they have charmed! i.e. If the PC is dominated, the enemy still attacks, and the effect is broken when they do damage to the PC. Whereas, if charmed, the enemy now ignores the charmed to go in search of another enemy … they come back to finish the charmed PC off after the charm has gone. Trying charm effect on a summoned … This appears to react in exactly the same way as if used on a PC. i.e. If it fails to save v charm, the enemy now ignores it and goes in search of other targets. The charmed summoned just appears to stand ground. NOTE: I think the creature attempts a save every round, and so sometimes, if saves almost immediately, then it remains the target of the enemy, and vice-versa.
FIFTH TEST …
INSANE & CONFUSED are very similar … possibly even the same hard coded effect … as when applying the INSANE effect, we get the same CONFUSED icon as a descriptor. The only difference that seems to be between the two is the statescripts associated with the effect type, as each does fire their own script. (And debug shows the different scripts firing.) Therefore, (and this is just a guess), these two may actually be examples of effects that work pretty much from the statescript scripts alone.
SIXTH TEST …
DAZED/STUNNED/HELD … Interestingly, x2_sig_state does NOT appear to fire when DAZE effect is used against a PC. … It DOES fire when with STUN. Finally, HELD (which uses the PARALYZE effect does appear to fire for both PC and summons).
CONCLUSIONS
I think the biggest concerns were surrounding the dominate effect and the NW_G0_dominate associated script. However, in my testing, NW_G0_dominate never gets called, no matter when EffectDominated was used, by PC or NPC, or if the target was a summoned. Therefore, the only result when an NPC uses this effect on any party member is to cause them to “freeze” (be unable to attack or move) until struck again, which breaks the effect.
Furthermore, although a dominated summoned creature is removed from the party, personally, I don’t see this as a problem. Firstly, it simply loses its attacks while dominated, which is broken the moment it is struck again by the enemy (which appears to be almost immediately). i.e. The enemy simply appears to use the domination as a means of getting a free attack rather than any specific control. Furthermore, as the heroes (who have now lost the summons) are going to continue attacking the enemy, the now (lost) summoned creature will automatically be unsummoned the moment the dominating enemy is killed. Therefore, the prime purpose of this DOMINATE effect (in my observations) is to…
A) Remove command control from its previous master. (Removed from party bar.)
B) Allow a free attack while dominated.
C) If the PC casts another summons, the original is unsummoned anyway.
The only potential negative (which to be frank, is limited anyway), is the fact that in the small time when the summoned is dominated, Greater Restoration does nothing. Although, practically speaking, there is little point in this anyway, as the effect will be lost when the dominated is next struck. I would consider a successful domination on a summoned creature as “beyond repair” - at least it does not rebel against the party, even if control of it is now lost. Just have to resummoned again if that is the case … and would be required id the new enemy dominating master is killed - unsummoning the summoned anyway.
From the perspective of the player, if they successfully DOMINATE a creature, then it is added to the party, and (I assume at this point) would fight for the party, albeit like a henchman without any direct control.
The CHARM effect appears to be quite a solid addition too. In some ways, even more useful than the DOMINATE effect, in that it “nullifies” an ally in the field, freeing the enemy to target something else, or even rest until the target is no longer charmed. And as the affected creature is NOT removed from the party, it is truly a temporary effect compared to the “more powerful” domination effect.
For the above reasons, I don’t think the check for PC is even required when using the GetScaledEffect.
IMPACT ON OPTIONS
With respect to how the effects work with the game difficulty settings, I would propose the following …
A) Allow DOMINATE and CHARM to work as normal, assuming the results work with the standard scripts as they have my own. (Especially with respect to unsummoning.)
B) Only substitute the DAZE effect when playing on EASY mode for certain effects. Maybe all those listed in the function already, plus DOMINATE and CHARM?
C) The FRIGHTENED effect has not been correctly implemented. It would require searching for the FRIGHTENED effect used in spell scripts and adding the GetScaledEffect check to them. The newly fixed version would then return the 4 attack penalty, making the overall effect better saves and movement at the cost of a worse attack (-4). (NB: By default, this effect adds -2 on all saves.) (Corrected.)
D) A closer look at the GetScaledDuration may help word the updated OPTIONS TLK entries too. (TBA)
E) Update options TLK entires: 67578, 67579, 67580, 67581. (May be easier to update XML and potential custom tlk.)
END REPORT - I BELIEVE.
1 Like
[observations]
- charm probly shouldn’t attack anything (edit: ok)
- a decision to attack a creature should be (generally) conditioned on
- target is not plot
- target is seen
- target is enemy
- target is not scriphidden
- target is not dead, perhaps not dying
eg.
if (!GetPlotFlag(oTarget) && !GetScriptHidden(oTarget)
&& !GetIsDead(oTarget, TRUE)
&& GetIsEnemy(oTarget)
&& GetObjectSeen(oTarget)
&& !GetHasEffect(EFFECT_TYPE_SANCTUARY, oTarget)) // 'x0_i0_match' (else attacker can hang on a Sanctuaried opponent)
{
ActionAttack(oTarget);
}
- Dominate seems to be the biggie. The simplest solution is ofc to disallow Dominate on all PC-faction. Note there are other pieces of code in Nwn2 that deliberately weed-out Dominated creatures in the PC-party.
// 'ginc_transition'
int RemoveDominatedFromPCParty(object oPc);
// 'x2_inc_switches'
// Removes effect and prevents transition if object is dominated - checked on
// transition ( ginc_transition ).
const string CAMPAIGN_SWITCH_REMOVE_DOMINATED_ON_TRANSITION = "N2_S_REMOVE_DOM_ON_TRAN";
also (but this one is for NPC Groups)
// 'x2_inc_switches'
// Force-kills dominated group-members if no valid members remain - checked on
// heartbeat ( nw_g0_dominate ).
const string CAMPAIGN_SWITCH_FORCE_KILL_DOMINATED_GROUP = "N2_S_KILL_DOM_GROUP";
that sounds good.
I’d be very leary of letting that happen … just sayin’
( a possibility is to treat a Dominated PC-faction associate (depending on type) as getting hit with Dispel/Banish w/ auto-success )
personally i’d be tempted to distinguish Charm from Dominate in the scaling functions, based on your tests : allow PC-faction Charm, disallow PC-faction Dominate … but it’s your call ofc.
heh. Wouldn’t surprise me :)
approaching the singularity (500 posts)
1 Like
Hi KevL,
(Ignoring game difficulty settings for the moment.)
The only two effects that are being “removed” (or changed to DAZED) with GetScaledEffect are DOMINATED and CHARM. And this is only changed for the PC (or summons they control) that the player currently controls.
I believe this is done to stop the player feeling/being totally “stuck” if successfully targeted by a dominate effect. i.e. If dominated, the PC cannot be controlled in any way.
The important point (and as it currently stands), however, is that all other PCs in the party (companions and their summons) CAN still have the charm and/or dominate affect them anyway! Therefore, this would imply to me that there is not any problem with the effects as such. After all, what’s the difference between the summon of the player’s current PC being dominated and the summons of a PC that the player is not currently playing? None, as far as I can see!
Furthermore, (and as far as I can prove), the associated dominated script (NW_G0_dominate) does not fire at all, under any tests I was able to do to date. (If you are able to double check at any time, that may be good to be double-checked, although I don’t think it’s needed if you see what I mean.) Therefore, nothing else is done to the DOMINATED target, other than whatever the hard-coded effect does to the target … which in this case appears to …
A) If a PC or companion … Simply stop them from being able to do anything for the duration.
B) If a summons (and others such like), remove them from the party. ( * )
( * ) The important point here being that this is STILL what happens anyway to all targets that the player is not currently controlling. i.e. That GetScaledEffect (as I already say) only changes such to DAZED for those creatures the player is currently actively controlling. So, if they have swapped to another PC, their Main PC or associated summons (if successfully target by a dominate effect), would also still have the DOMINATE (or CHARM if that is used) applied.
Therefore, unless we have experienced any problems with gameplay in NWN2 to date, I don’t think the check (for player possessed PCs only) has any bearing, other than not to immediately “lock” the player’s current PC out of their control.
So with reference to the conditional checks you mention, I don’t think they are needed, as these effects do not appear to do anything over and above to anything in particular to what we already experience in the game. NB: I am talking about the DOMINATE and CHARM effects only at the moment, as I do think there is need for those checks with respect to other effects which force the PCs to attack a target when using the AttackTarget function (like confused does). Thankfully, the CHARM effect uses HenchDetermineCombatRound, and so that already takes such things into account. This is why I changed the NW_G0_confuse effect script to check for “nearest creature seen alive” rather than just “any creature”, as that then goes on to use AttackTarget.
DOMINATE: It is good to know about the RemoveDominatedFromPCParty, as that may explain how these have been handled with respect to certain other aspects of coding. Thanks for that. I was aware of the CAMPAIGN_SWITCH_FORCE_KILL_DOMINATED_GROUP, and that still functions, but is employed via the heartbeat script now and NOT the (redundant?) NW_G0_dominate script. Also, it is switched via a module variable anyway, so some mods won’t use it anyway (like mine does not).
Yes, I considered both of these points too.
However, for the first point, I did wonder if we would “lose” something by doing so … As I quite like the idea that the PC loses control of their summons, making them decide if they are going to cast the spell again to regain control of their summons or not.
On the second point, I am still mulling over how to adjust the effects according to difficulty settings. Once I know (for sure) there are no problems using DOMINATE and CHARM irrespective of whether the PC is controlling the PC in question or not, will free me to consider these options too. However, I am almost certainly in agreement that an easier setting should perhaps convert DOMINATE > CHARM … and perhaps even this … For an initial DOMINATE effect …
D&D (Or DIFFICULT): STAYS AS DOMINATE.
NORMAL: DOWNGRADES TO CHARM.
EASY: DOWNGRADES TO DAZED.
Thanks, Lance.
Here is a screenshot showing how the Main PC has been dominated as I was not controlling it when the dominated effect was made … So, I am as confident as I can be, that unless there is any good reason (other than not freezing the player’s current controlled PC), then we may be able to remove that check from the GetScaledEffect function. As it does not stop the effect on any and every PC (and their summons) regardless of which PC we are talking about, unless the player is currently possessing it …
You may need to zoom in on the top right of this image … The Main PC was “dominated” while I was playing another PC, and I was able to switch back to it (so that’s not a problem either) and was then unable to do anything … as expected …
I am going to write a NEW GetScaledEffect function, which will now simply adjust effects due to difficulty setting (ignoring VERY EASY, which cannot be set anyway), and post it when done … I will also take a look at some of the other effects and suggest some in that function too.
UPDATE:
FRIGHTENED: This effect was not calling GetScaledEffect anywhere anyway (as it currently stood). Deleted comment here, as I was incorrect.
The more I look at this function (GetScaledEffect), the more it seems to me that its original intention (which it failed at) was probably to ensure the player kept “control” of the PC they were currently playing at all times. I say this because, reading between the lines, the targeted altered effects are all to do with ensuring the player does not lose “control” of there PC, even though the frightened effect was broken in application anyway.
So, if a “proper” fix was put in place, my guess is that the fear effect (which every difficulty would have seen their PCs run away from an enemy) would no longer do this for the EASY setting. Instead, they would simply have a -4 on their attack roles. With this in mind, it raises a question, should this now be retrospectively fixed, to come in line with the options?
As we are close to the posting limit, I may also start a new post with respect to asking about the “OPTIONS” settings. However, I still appreciate feedback with respect to testing etc here.
SERVER DIFFICULTY: By the way, in case it was missed (and to remind myself), the VERY EASY setting is available if running from a server. Then the value can be zero (VERY EASY).
i believe that is or should be the point of all these adjustments.
you’re (very) probably right
I’m just naturally/instinctively (very) skeptical … especially of Nwn2 code/scripts ;)
will do
Danger! Danger, Will Robinson!
- when crafting the DM-helper i did a LOT of adding and removing creatures from the PC-party. While typically robust it tended to leave a bad aftertaste …
that’s why i suggested that if an associate is removed from the party – just dismiss it completely.
… may or may not be non-trivial /shrugz
is something to be mindful of imo.
definitely.
that could well be … but that alone doesn’t account for their condition regarding the associates of player-controlled characters …
in other words they screwed up so yes it is up to you/me/him/us/the other guy/gal to fashion a more consistent policy. (which i’m aware is exactly what you’re attempting)
definitely. (see above;)
yepz noted tks
Thanks!
I am definitely considering this too. Initially I felt that it may look too similar to Dismissal, but as they are similar level spells, I may just go with it. Especially as there is the other
CAMPAIGN_SWITCH_FORCE_KILL_DOMINATED_GROUP switch that was considered at the making. i.e. That amounted to a similar “permanent remove” aspect. Therefore, I think (to be safe) I may well go this way too. I may even employ this switch for NPCs successfully targetting any summons/familiar/companion with Dominate (and not as just the last in a group)… and may even allow a failed effect (if creature makes save) when using Dominate … thinking. (Maybe Charmed instead of dominated, for the failed attempt. But would that make Dominate too powerful?)
That’s the plan … I am just a little “hampered” by making sure I don’t alter balance too greatly. My biggest concern being how these scaled functions affect the player’s current controlled PC (and their associates) only … so altering the effect for every target may be going too far.
BUT … I believe it would make more sense if the effects were consistent no matter the target … and this is my goal.
Thanks again, Lance.
EDIT: I thought I had found another bug, but it wasn’t. (So deleted!)
UPDATE
I am considering biting the bullet and looking over many spell scripts again … especially in the light of some of the mentions in this project. <<<< I am not convinced by some of these alterations. (I spent some time going through one of the include changes and did not think any were warranted.) … Are you aware of any that may be worth considering? (If you ever checked it I mean.)
I mean, if I am going to look at Scaled differences for some spells, then I may as well do it at the same time. I also have some of my own code I am considering for module 2. However, it feels like a big task, and I am not sure how long it will take … I just thought I’d mention it, in case you wanted to add any comment that may ease the potential task.
EDIT: I’m hoping the XML will accept a custom tlk entry, as it has this entry regarding options text …
update=true OnUpdate=UIText_OnUpdate_DisplaySliderText(“SB_DIFF_LEVEL”,“true”,67578,67579,67580,67581)
OK, well it works, but currently only after the campaign has loaded … i.e. I have yet been able to place the XML anywhere where the text is delivered after the tlk has been loaded. So, if the player looks at these setting before entering the module, then the old strings/texts are returned. (NB: I did try placing the xml in the custom UI, but the custom tlk has NOT loaded by then, meaning we get some other inappropriate tlk ref show that relates to the first few numbers of my custom tlk values.)
Options showing changed text after the mod/campaign loaded … Of course, I may just be able to use straight text strings directly in the XML itself … I’ll try that next. … Nope! Fails.
UPDATE: I noticed something interesting with respect to tlk file … I was trying to make the XML use my custom tlk ref 16777457, as that is where I altered and entered new rule text. This works fine if the tlk file has loaded after the initial screens, BUT PRIOR to loading the custom tlk, this ref appears to return the 2da value instead … which in turn associates with a different tlk ref. 241 in this case … but note it got this from looking up the 2da ref instead!(See image below.) I am wondering if there may be a way to exploit this to place some different text along the lines of “Not Yet Available” or “Use In Game” (if these official tlk file entries exist) and use a custom tlk entry that relates to these, so it works both before and after the custom tlk has loaded. (Too complicated as would require four entries anyway.) … Or maybe it is easier just to edit the original tlk file, but I know this is considered taboo. < = I tried this, but my tlk prog failed.
1 Like
Hi KevL,
I have my own functions when trying to determine if a party member has been targeted. However, I am trying to stick to standard OC functions for this “fix”, and so ask how you would do this using standard OC functions only?
i.e. How does one check if a target is a member of the party?
Furthermore, I can’t use GetFirstPC, because that can return a DM if used.
As I say, this check is straightforward using my own functions, but maybe there is a sure fire way using standard OC functions, but I’m not seeing it at the moment … hopefully it’s a straightforward answer for you. 
I can’t even compare factions, because that only works between two NPCs.
I also think I am just tired, so may take a break.
Thanks in advance, Lance.
Edit… I just realized that you are saying that function will only return a valid object for a party member. Is that it?
yep. Ever since i saw it in the core AI scripts i’ve used it this way and its been solid for me:
if (GetIsObjectValid(GetFactionLeader(oTarget))) // is pc-faction
or to be really strict one could loop through GetFirst/NextPC and check the returns for !DM + GetFactionEqual(oPC, oTarget)
ps. custom talktable refs - I remember reading that if the custom entry is not found use the corresponding entry from the standard talktable …
( which … i roll my eyes at but there it is i guess )
TlkEdit2 has never borked me in a decade. I don’t like somethings about it but it has been solid for me.
OK, I’ll take another look at that on Monday.
I think I have that, but may not have realised it handled tlk as well. Or… it was a prog that stopped working … I cannot recall, and not at my main computer at the moment to check …
Again, I guess I can check later … but I may try that then, just to see the result … Out of interest, what is your thought on supplying an altered original.tlk file?
Catch you later … Thanks, Lance.
uhm very tough call on that
if true put a BIG note under installation docs* about it.
start with the biggest one there is: from Kaedrin’s PrC pack
remember that if it’s put under Documents/NwN2 the changes won’t appear in the toolset; if under installation/NwN2 they do.
respect 2da reserved ranges
* including what entry #ids changed so that people can merge them into their own manually if need be/ if they really want to.
Hi KevL,
I remembered why I stopped using that app (TlkEdit2) … I had to reinstall Java. … Which I have done now, and it works …
However, I have decided to NOT alter the original TLK file, and just go with an altered version of the options after the game has loaded. i.e. Normal settings text when NWN2 first fires up, but with Althéa options when in game.
As most people won’t probably realise any differences to begin with (even if fixed), I decided that the correct text is probably not a huge issue … and a player can easily confirm it after loading.
EDIT: By the way, I edited a couple of my comments above to reflect my initial error at thinking FRIGHTENED returned the effect as well as the penalty. My bad, as it was not.
EDIT 2: GetFactionLeader(oTarget) … I will go with that function then. I imagine that while we have the SetFactionLeader function, that nobody is going to use it with a non-player creature. I don’t use it in my own module.
Thanks, Lance.
2 Likes
i don’t think it works outside the party … needs a retest (i recall vaguely doing this a decade ago)
// 'setleader'
//
// console script
void main()
{
object oTarget = GetPlayerCurrentTarget(OBJECT_SELF);
if (GetIsObjectValid(oTarget) && GetObjectType(oTarget) == OBJECT_TYPE_CREATURE)
{
SetFactionLeader(oTarget);
object oLeader = GetFactionLeader(oTarget);
string sLeader;
if (GetIsObjectValid(oLeader))
sLeader = GetName(oLeader) + " ( " + GetTag(oLeader) + " )";
else
sLeader = "INVALID";
SendMessageToPC(GetFirstPC(FALSE), "leader= " + sLeader);
}
else
SendMessageToPC(GetFirstPC(FALSE), "ERROR : target a creature");
}
printed INVALID on Ginni Lannon as well as a hostile lizard …
(despite what’s implied in nwscript.nss)
1 Like
Hi KevL,
Thanks for testing that! 
That is certainly good to know.
As you say, it was implied it could be set outside a party, but good to know it can’t be.
I am just working my way through some settings/options for the different effects for settings. I am still in two minds about the dominate effect, but will probably go with an “instant dismissal” effect on non-pc members and charm on PC members.
I am also struggling with what to do with scaled durations … I mean if I am going to change the function to scale durations for every party target (and not just the controlled PC at the target time), then I am not sure I should lower by as much for every target … I am considering using 0.75 and 0.5 durations instead of 0.5 and 0.25 … otherwise it may be a little too generous, even for the lower settings.
Thanks, Lance.
I currently have … I must make some decisions … 
////////////////////////////////////////////////////////////////////////////
// SCALED FIXES (LB UPDATE) - AFFECTS SPELL SCALING EFFECT WHEN OPTIONS CHANGED
// NO LONGER MAKING ANY DISTINCTION FOR "VERY EASY" SERVER SETTING
////////////////////////////////////////////////////////////////////////////
effect FIXEDGetScaledEffect(effect eStandard, object oTarget);
effect FIXEDGetScaledEffect(effect eStandard, object oTarget)
{
// CHECK IF A PARTY MEMBER
object oPC = GetFactionLeader(oTarget);
// CHECK IF A PARTY MEMBER
object oMaster = GetMaster(oTarget);
oMaster = GetFactionLeader(oMaster);
effect eNew = eStandard;
// MINIMUM ALLOWED IS NOW 1 (EASY)
int nDiff = GetGameDifficulty();
if(nDiff == 0){nDiff = 1;}
if(oPC != OBJECT_INVALID || oMaster != OBJECT_INVALID)
{
//SendMessageToAllPCs("PARTY MEMBER TARGETED");
}
return eNew;
}hey Lance
sorry i can’t really be of much help on specifics (about what should be done)
but here’s some advice : don’t bang yer head on it … keep things very similar to the way they currently are
just fix the bits that don’t quite make sense
generally
ps. started Nwn2fixes part2
Am going to call @Tarot_Redhand for this thread to be locked. Or just let it play out TR … see what happens?
@Lance_Botelle feel free to continue here or in the other thread
1 Like
I recently noticed this known issue with NWN:
In a few special cases, a negative primary ability modifier triggers a bug that causes the DC to become rather large (127 or more). These special cases are fear (feat), shadow daze, sleep (feat), and custom feats whose script combines GetSpellSaveDC() with MySavingThrow().
Do we know if this still happens in NWN2? Just curious if this has been patched.
curious… I’ve never seen it happen (explicitly) but peepls should keep their eyes open and try to test it if they get a chance
Hi @kevL_s : this set of files provides fixes for the stock PLC_MC_CHANDL01 and PLC_MC_CHANDL02 chandelier models. For both chandeliers it increases the swing amplitude to half a degree, so it is still subtle but at least visible to the player’s eye. For the second chandelier it corrects the height setting so that the top of the chain lines up with the static component.
https://drive.google.com/file/d/1ylYkV6rVjMmsyo2nalI_QpLYWOcaBpU9/view?usp=sharing
Please let me know if you have access problems – I made it public.
1 Like
okie doke
also, i hope this works …
For example i can’t remember if Okku is supposed to do his levelups auto. Or what would happen, exactly, if ResetLevel() should be called …
goto thread – Nwn2fixes part2
1 Like