The Black Scourge of Candle Cove -- Tchos' development diary

[Tchos]

All this time using it, and I'm still finding useful features I haven't been using the in the Powerbar plugin, like selecting an environmental object and automatically placing a walkmesh cutter around it, with optional amounts of padding. However, its variable editor doesn't seem to work reliably. I used it to add and remove some variables to an object, only to find my changes were gone next time I clicked on the object.

Today I reworked the trigger script gtr_bark_node. The normal script works very nicely for my recruitable companions. You can assign a hierarchy of priority for which companion should say something, if they're present. The way I have it set up here, whichever companion the player has in the party who has the most relevant or the most interesting line will be the one to speak up, which is how the normal script works. But in addition, if the player has no recruitable companions in the party, then it defaults to a skill check, and the first player-made party member who passes the skill check will speak up, with a bit less personality (but one which can be inferred from their choice of skills), to ensure that the player gets useful feedback and a little flavour in the areas.

At first I accomplished this effect with two triggers, and an On Enter script that would destroy the one for player-made party members if the player has at least one recruitable companion in the party, but I didn't want to do that for every area, and some areas have multiple triggers, so it would get complicated fast. The single-trigger solution works better.

In a test today, I found some unexpected behaviour. I had teleported directly to the kuo-toa temple to test out some of the kuo-toa AI, as well as the quest items, when I saw some sahuagin approaching the temple! The sahuagin had never approached the temple before, and they're from a rather distant subzone. I went to check on the rest of them, and found the whole lot of them crowded around a locked door barring their way to the temple, which promptly exploded as they detected me. So all of the sahuagin were trying to get into the temple, when before they had stayed patrolling their base camp.

This began when I added generic stop waypoints around the temple, which I had intended for only the kuo-toas to use. I had no idea that creatures from all across the map would attempt to approach those waypoints, when they barely seemed adequate for creatures nearby.

The solution seems to be to just add some stop waypoints in each subzone where there are creatures set to wander around. That should keep pulling them back if they try to wander off toward one of the other ones.

I modified my waypoint spawning script so that now I can add inventory items to specific spawning waypoints, so that I don't need to create separate blueprints for creatures of the same basic type that need to possess specific items.

I think I mentioned before that I created an alternative placeable script to generate random treasure on containers, exactly like the SoZ creature loot script, so that you can also specify loot tables with percentage drop rates for the objects, as well as specific items.

I created another alternative that simply picks items from a list of all possible consumables and crafting items in the OC, except it allows you to switch on or off any/all specific categories of items to pick from. For instance, you can set it to pick only scrolls if you put it on a wizard's scroll case. Or you can set all categories on if you're opening a box at a rummage sale. Also you can set a minimum and maximum number of items to generate. This all helped fill the containers in the temple with relevant items.

The temple is functional, but I'm still polishing it, and there's still some dialogue to write, such as for the last quest. Some of Kalister's resources have come just in time for my needs. [Note: Kalister uses two spellings, and he told me that that this is the preferred one.]

I'm concerned about this cave area. It's starting to become difficult to open in the toolset without crashing. I need to get the rest of the roofs and walls placed in there before it goes the way of the docks. Anything else, I think I can add via script if necessary. The walkmesh is finalised.

[Tchos]

I did the blocking script for the actions of the character in the last quest. Another assortment of animation, visual and sound effects, and placeable manipulation. I think it works pretty well, though it's still missing the animation file I really wanted to use for it.

I figured out what was wrong with the progress bar code that was causing it to remain on the screen if the player switches party members while it's in progress. I have code in there to prevent the player from switching party members in those cases, but it doesn't prevent you from switching to the main character, which is where the UI was getting stuck. I don't know if it's possible to temporarily set the main PC to be unselectable as it is for the companions.
Anyway, all it took was a loop through the party to remove the UI when it's supposed to be removed at the end of the task.

I wrote a few new utility and helper scripts that are useful for the kind of quests I include, and one that addresses a limitation of the quest indicators -- in that they can only update the indicators on creatures that actually exist. Since I spawn an area's creatures only when the PC enters the area for the first time, sometimes a creature that I want to manipulate through a script doesn't exist yet, so I made a quickie little ga_ script to check if a creature exists, and if not, then spawn it and mark the waypoint so that it won't be spawned again later when the PC enters the area. This is useful not just for the quest system, but also to ensure that kill quests can be completed.

Also added another new ga_ script to toggle an arbitrary number of lights on or off based on their proximity to any reference object, since tags don't work for lights. This needed some debugging, because I forget that GetNearestObject() starts with 1 instead of 0.

I'm having trouble with a secret item. The script works elsewhere, but here it's firing once and never again, based on the debug text appearing only once for On Enter, and never for Heartbeat. Nothing in the script is set to disable it or destroy it after it's triggered once. The only thing I can guess is that the walkmesh might have something to do with it, because it's elevated above ground level, and whenever you draw a trigger, it drops the trigger to ground level even if you have a placeable with a walkmesh over it. But then why would it fire the On Enter script even the first time? It fires it because there's a creature standing in it, but that shouldn't prevent it from firing again on the heartbeat, or when someone else enters it. I don't get it.

Also added another wastebasket for players to dispose of unwanted items.

I'm actually not able to connect to the Neverwinter Nexus file site at all, and haven't been for weeks. I think I occasionally could around X-mas, but now every time I try, it just times out. No idea if I'll be able to upload this module when it's ready.

[Tchos]

This marks the point where I left off on updating two simultaneous threads at the time, since the feedback here had been low, but since the Bioware forum is closing down, I'm copying all of the posts that I had omitted here for safekeeping.

 

Also, to address my last paragraph in the previous post, the reason I was unable to connect to the file site was that the site structure was no longer using the URLs with subdomains in front of the address as in neverwinter2.nexusmods.com, and had switched to nexusmods.com/neverwinter2.

[Tchos]

I finally soldiered through a couple of quest conversations that were holding me back. Too many conditions, alternate paths, etc. The result is not as nuanced as I had in mind, and I can't say I'm satisfied with the way the quest ends as a result, but I had to push it through. I can fully understand the appeal of doing quests with little or no choice in the dialogue. It would take so much less time.

 

I haven't tested the conversations, but the first one should work, since I had tested the skeleton of the conversation before fleshing it out.

 

The quests are all done, then, and the only major thing left is to fill in the companion back stories, which basically amounts to more conversation work. There are many other little things that could be done, looking at my to-do list, but none are really necessary to get it out.

[Originally posted 29 March 2014 - 02:18 PM]

 

Have there been many additions since the first beta?

 

Not all that many. A few quests. A new dungeon section (the kuo-toa temple). More companions. Lots of corrections and fixes. I'm pretty happy with the temple.

 

I took the view early on that multiple outcomes to quests should be used only when I felt that it really added something to the overall plot/feel of the module.
They are not just hard to create but really hard to debug.

 

Yes, though the debugging isn't too bad since I'm using the journal state as the primary means of determining which dialogue nodes to show. I'm not using much of the fallthrough method at the moment.

 

The dialogue options I've been doing have not been adding that much to the overall plot or feel, but are in some cases just trying to give support for neutral or evil type players, even though I really don't think an evil character could justify doing the main quest, so I'm not sure how much good it does to support such options in the side quests. I still like having some tone options, though.

 

Lot of fortitude indeed. But I think it's worth it. Multiple outcomes mean re-playable mod. I was just doing a quest myself with 4 different outcomes. And yes, the convo is a pain on such occasions. By the way, if you need to test the final version you know you can always ask me .

 

One approach I sometimes use is to have just one outcome for a quest, but to offer multiple ways in which to achieve it (hack/slash, stealth, rogue skills, conversation skills, etc). That makes the quest-giver's conversation easier to handle, since all they care about is that you achieved their goal, not *how* you achieved it. When dealing with adventuring types, it's often best not to ask too many questions.

 

Sometimes I'll offer good/neutral/evil nodes to give a conversation flavour, even if they all lead to the same generic response. At least then they offer the illusion of choice, without me having to test lots of convoluted conversation options relying on multiple variables.

 

For some of the conversations, I use variables like "Annoyed", "TrustsYou", etc. on the NPCs, depending on what you do, to the point at which I decided I might be better off just using a kind of reputation system that tracks both personal and faction-wide reputation, similar to an influence system. I might end up doing that in future works.

 

It's not extensively used here, but there are some places where an NPC will refuse to help you further if you've treated him/her poorly, unless you make reparations.

[Tchos]

It's been a while since the last update, but I've gradually been doing things in that time, while academic obligations have largely kept me otherwise occupied. I have to admit that some of my free time has been spent actually playing games as well. Anyway, back to the diary.

 

I had been having trouble with the usual trigger-based hidden object spawning, which I think may have been due to the walking area being far above the trigger on the ground on top of a walkable placeable. I found a different resource for secret items in the stock resources, in the form of an ipoint with a certain heartbeat script, in the "misc. props" blueprints. I generally avoid gratuitous heartbeats to avoid bogging things down, but I can activate it and deactivate it in the area enter/exit scripts if need be.

 

It's rare, but I have played a couple of modules which had a noticeable pause in the gameplay every 6 seconds, which I presume is due to too many objects firing their own heartbeats. Usually, I spawn objects with heartbeats as I need them, and destroy them when I'm done. That has become my go-to method of making special things happen reliably for a limited amount of time, without interference from, say, an NPC's heartbeat script. An even more economical method would be to set an existing blank-scripted object to use a new heartbeat when I need it, and then remove the script from the slot when I'm done. There are plenty of scriptable objects already in the game, like all of the containers, which don't normally have heartbeats, which could serve as that kind of temporary controller.

 

Unrelated, but I finally got around to modifying the override version of the PC Tools scripts to allow me to use the PC Tools interface to apply the emote animations to other party members rather than just the first PC, and even to NPCs outside of the party by targeting the one that I want to emote.

 

I finished up the last quest dialogue, and now it's just waiting on the rest of the companion dialogues, and some little annoying things I've wanted to fix. One is that for the diving quest, I have to unsummon any familiars or animal companions, because they wouldn't have swimming animation (nor diving helms, so they'd drown anyway if they were there). kevL pointed me in the right direction (summary: use the same approach as Banishment or Dismissal -- which is to kill them).

 

Another thing is that I want the civilian kuo-toas (the weak, low-level ones who are just attending the temple) to flee if they see the adventurers, and alert any temple guards and other armed kuo-toas to seek the adventurers where they were last seen by the fleeing civilians. Pretty straightforward to do, but a bit tedious.

 

There's also a matter of tying up a couple of loose ends. There are three signs and two notes in town that mention the trade embargo. Since I mean to expand this module, I should change their descriptions to updated information at the end of the main quest. I didn't have some of those objects' tags listed in my catalogue. Since I can't open the area in the toolset, I had to write a script to tell me the tags of the several placeables nearest to where my PC was standing, so I could go around in-game and enter them into the catalogue for scripting the changes later. I have a similar script to illuminate nearby waypoints and report their tags to me. This info-gathering also gave me the tags for several doors (placeable doors) which I placed to be activated as needed. There were a few that I forgot to enter into the catalogue.

 

Another loose end was that I wanted a character to leave after the completion of a quest, except not right away. He would need some time to pack up, after all, and I wanted to give the player some time to access his shop before he goes away for good. To accomplish this, I created a generic heartbeat script to be applied to an ipoint. The ipoint and its necessary variables can all be created using ga_ scripts, plus a custom one to assign it a heartbeat script (I create far too many temporary ipoints to want to make blueprints out of all of them, differing only in what scripts are applied), but later I'll probably want to create another ga_ script to handle the object creation and its variable and script assignments that I can enter in the conversation fields. I tested it out on a 4-round delay, and it worked fine, so I made it so that he'll actually hang around for several days before leaving. This new script supports both the standard "force exit" which destroys the NPC when it "exits", and a new function that jumps the NPC to a second waypoint (such as to a holding cell, or just to its new home/shop/whatever) after reaching the "exit" point, which looks the same if you're watching it, but leaves the NPC intact in case you want to access it or bring it back later with all of its stored variables intact.

 

I tried to create a "blocker" object for the purpose of blocking LOS, for use in putting either outside of placeable-constructed environmental object walls, or above the ceiling line of tilesets, to keep the camera behaved nicely when angled over the top of the walls. For some reason, it wasn't working with my invisible object with a C2 mesh, which was set in the placeables.2da to "BlockLOS", whether I baked it or not, and whether dynamic collisions were on or not. I also tried using the stock collision box with dynamic collisions both turned on and off, and a city tile block with various settings. It must be said that I only really tested this above the ceiling line of two different tileset rooms, so it's possible the ceiling has something to do with it. I haven't tried it yet for placeable walls.

 

[Originally posted 13 May 2014 - 01:23 PM]

 

Eureka ! That's why my laptop got a bit jumpy every few seconds in an area I remade recently. I thought I'd overdone it on the grass etc. but it's the wandering animals heartbeat from me setting them all with the ambient spawn variable... They will all be trapped and barbequed !

 

Keep on tapping away at your keyboard, it sounds like you're nearly there !

 

Well, it depends on how complicated the heartbeats are. Wandering may not be particularly strenuous, unless the pathfinding is particularly difficult in that area. But it may help to have the area's heartbeat controlling all of the creatures, looping through them and assigning them commands instead of firing a separate script for each one. Not sure.

Edited August 1, 2016 by Tchos

[Tchos]

I started integrating the crime and punishment system I showed in this video before, from the test module to the Candle Cove docks. One challenge in doing this was that all of the civilians and most of the city watchmen walking around in the docks are placed instances, and I of course can't open the docks area to modify their scripts.

 

The crime and punishment scripts rely on certain listening patterns and spawn-in conditions to be set on the civilians and the guards. This is usually done in the On Spawn script, but these NPCs are placed, so they'd already have spawned before I could reassign their scripts through another script. I edited the SetSpawnInConditions() and SetListeningPatterns() functions (internally, not globally) so that they would take an object parameter instead of only working on OBJECT_SELF. Then I added a loop to the On Client Enter script to cycle through the NPCs and apply either the citizen or the city watch listening patterns and On User Defined Event scripts, as appropriate.

 

The next problem was that when I tested it, the citizens who were walking around would keep walking around when I attacked them, though they would yell to the guards that they were being attacked. Once they reached their prior destinations, then they'd run to the escape locations (any door waypoint). Fixed by adding an appropriate ClearAllActions() command.

 

Next, the guards were walking casually to me instead of running, as they're supposed to (the command has bRun set to TRUE). I may have set their movement speed to walk-only, but I don't think so. When I checked the movement rate by script, it reported that it was "4", but I don't know how that corresponds to the names in the dropdown list for movement speed. It also reported that the movement rate factor is 1.0 (a multiplier for modifying the movement rate, such as for slowing down in difficult terrain). I'm testing whether setting it to 3.0 will make them speed-walk or actually run.

 

Next, they weren't firing the conversations. They'd walk up to me and then turn around and go back to what they were doing. I think this was because I was still "in combat", but I don't know why it was a problem here when it wasn't a problem in the test module. I added another ClearAllActions() to the script, to be fired on the player just before the guards attempt conversation, and that fixed it.

 

Next I need to add the jail penalties and a fade out/in, and make nearby citizens react to the violence as well.

 

[Originally posted 15 May 2014 - 12:40 PM]

 

There also seems to be some things from SoZ that are called OnHeartbeat that cause some perf issues (e.g. the clock). Shallina is convinced it has to do with anything on the GUI being updated through heartbeat, but I'll be testing that theory this weekend or early next week. I'll let you know what we find out :)

 

Well, I would be very much interested in your report! Thank you, Drew.

 

No problem! I'm very interested in seeing your project; it's been great to read your dev journal so far :)

 

[Tchos]

Small details again.

I designed a more flexible, general-use system to replace the PC fleeing system that comes with the game, as I found it to be too narrow. The idea is to allow me to use variables to specify an NPC's particular preferences as to where to flee to, and what happens after that. This is for use not only for the citizens, but also for the civilian monsters.

It took a lot of trials and bugfixing, but I have it working. The last thing that confounded me was figuring out why they were fleeing toward the nearest waypoint with the assigned prefix, when I had told these ones to flee to a specific waypoint instead. The reason was a simple mistake in the name of the variable (I wrote FleeToSpecificWaypoint instead of FleeToSpecificWP).

They're still not getting healed during their away time, as I wanted.

I've spent some time trying to fix some problems with the statue script from long ago. Every time I enter the area, the statue was in a slightly different pose. I made some changes and made sure that the script fires only once, but now it changes the pose once. The first time it's in a good pose, but every time afterward it's in a very unartistic, nearly-default pose. The creature has no scripts, and the petrifying code is this, which I mainly got from Bob Hall's toolset notes:

    float fDelay = GetLocalFloat (oNPC, "Delay");
    string sAnim = GetLocalString (oNPC, "Animation");
    PlayCustomAnimation(oNPC, sAnim, FALSE);
    effect eFreeze = SupernaturalEffect (EffectVisualEffect (VFX_DUR_FREEZE_ANIMATION ));
    ApplyEffectToObject (DURATION_TYPE_PERMANENT, eFreeze, oNPC);
    SetBumpState (oNPC, BUMPSTATE_UNBUMPABLE);
    SetIsDestroyable( FALSE, FALSE, FALSE );
    ApplyEffectToObject( DURATION_TYPE_PERMANENT, EffectDeath(), oNPC );
    SetPlotFlag (oNPC, TRUE);

I think it has something to do with the definition of VFX_DUR_FREEZE_ANIMATION, which is a duration-based effect, not a permanent effect. According to the 2DA, its ProgFX Duration is 1300 (seconds?)

 

I made my first attempt at the dismissal of minions for the diving section, for the reasons mentioned in previous entries. I wasn't sure if minions were counted as "faction members" and would therefore be included in the same loop that equips the diving helmets and wet suits, but I tried it anyway and found that they were indeed included.

 

However, it only dismissed one of the two minions I had in the party (a familiar and an animal companion), though it dismissed the other one when I went on a second dive. I believe this is because killing the minion (which is the way dismissing is done) breaks the loop, preventing it from going through the rest of the faction. I'm trying again with a delayed command.

 

One thing that I wasn't planning to address was the fact that after the dive, when the helmet and wet suit are removed, the party remains naked. But I found a couple of commands in the ginc_items include file that sounded like they'd address the issue without trouble, namely RememberEquippedItems() and RestoreEquippedItems().

 

For unknown reasons, it didn't work. I looked through the functions to see how they worked, and they seem a bit inefficient. They store variables on the equipped items that mark them as having been equipped, and which slot they go in, and then when it's time to restore them, it cycles through the whole inventory looking for items with those variables, and then putting them back in the slots. I'll write a different pair of functions that stores local objects on the faction members for each equipment slot, and see if that works.

[Tchos]

I've fixed the bugs in the fleeing system. The NPCs get healed now, as they were supposed to. My mistake was failing to include references to the intended object with the functions to get the max and current hit points.

 

The party is no longer naked when they return from the dive, with the exception of the main PC. This seems to be because equipping items is an action that goes in the action queue, and the immediate jump to the other area interrupts or clears the action queue for the main PC, but not the others. I was able to equip the items by throwing in a ClearAllActions first, but this resulted in the main PC not transitioning to the other area with the rest of the party, leaving him stranded. Apparently it cleared the action of jumping to the next area even though that was a second script that was supposedly being executed after this script (it was on the same dialogue node, but in a lower position). I could fix it by adding some code to the area On Exit or the other area's On Enter scripts, but for now I'm just going to leave it like this.

 

There was a strange bug caused by the way I had to implement the crime and punishment system. As mentioned a couple of posts ago, I had to apply the necessary scripts to the placed instances of the NPCs through a loop. Well, it applied the scripts to the player's party, too. I tried a few conditions to prevent this, using GetIsPC and GetIsOwnedByPlayer conditions for the loop, but it didn't work for all of the party members (I tested with both player-created and recruited party members). The way that succeeded was to use GetFactionEqual testing to make sure the NPCs are not in the same faction as the main PC.

 

I also succeeded in dismissing the familiars and animal companions before the dive. Since the way dismissals are done is by actually killing the creatures, I was afraid that doing this would apply a penalty to wizards for the deaths of their familiars, as is supposed to happen. It didn't happen, so no problem. The way I got rid of all of them without breaking the loop was to assign them a heartbeat that would self-destruct after a brief delay. However, I found that they left behind loot bags. When I checked the loot bags, it was the diving helmet and suit, because all party members, including the familiars and animal companions, were given those items. Oops. Rather than prevent them from receiving them, I just added a routine to clear their inventory before destroying them, which worked.

 

The statue problem has not been fixed, but my experiments seem to indicate that it loses its pose because the freezing VFX doesn't persist between area reloads, and since the death effect is applied to prevent the statue from being selectable, it can't restart the animation and re-freeze on return visits. The solution may be to remove the death effect and re-run the animation and freezing on each entering of the area, and let it remain selectable, despite that making it seem like there's something you should be able to do with it. Resurrecting the creature each time seems like too much.

 

[Originally posted 04 June 2014 - 10:59 AM]

 

Making the statue selectable is not such a bad thing. It could have an one liner convo, and when I click it it could say something like "This statue represents a heroic man", or anything. He just needs to not turn when spoken to.

 

That's a good idea.

 

The headaches that creature statues can cause are the main reasons why I developed VFX statues. They have the advantage of not being selectable, but with several disadvantages of their own. It seems there's no perfect method of creating statues from creature models, short of using modelling software to convert them into placeable models (even then you only get one pose per model).

 

What are the disadvantages?

[Tchos]

I prettied up the "going to jail" experience for crime and punishment, adding a fade to black, a jail door sound effect, some text, and a temporary attribute reduction. I expected that the attribute reduction would require a restoration spell/potion, but apparently it just goes away on its own.

 

Found a couple more bugs, like one caused by checking for a local int with a certain name when I set it using a slightly different name. Also commented out some debug text now that those parts are working.

 

Still another bug is that the watchmen aren't reacting properly if you attack them. Partially correct, but not fully.

 

Also, the citizens aren't playing their voice cries when they flee, as they do in the separate module where I worked on the system originally.

 

The to-do list is still getting smaller, despite adding new bugs to it.

 

(later)

 

I got the watchmen to immediately arrest you if you attack them, and also fixed a new bug I found where if you resisted arrest it wouldn't reset the dialogue if you pay the fine or go to jail. This was because I had specified a script that I hadn't written yet.

 

I also fixed the citizens failing to play their voice cries. I just had to add a tiny delay to the command to execute the make_npc_flee script. I have a function to randomise the cries for help, and to play appropriate voices depending on the NPC's gender.

 

[Originally posted 06 June 2014 - 04:46 AM]

[Tchos]

I'm working on the last few companions. I spent quite a while on the gear for the wizard, because I wanted gear that looked good, matched with the head and body, and had interesting attributes. I like the kind of gear that has both advantages and disadvantages, with the advantages enough such that you may want to wear it anyway.

 

Since there's not really the same sort of thing on the wiki for clothing and armour as there is for reserved ranges, I went ahead and made a spreadsheet of all of the clothing I have, which numbers it uses in which category, who made it, which races/genders it works for, etc., so that I could renumber conflicting gear as needed.

 

Much of this gear has trouble matching skin tones, as I was discussing with Xaltar in his head pack thread. For the gear I'm using in this module, I've edited the textures and their specular maps so that they work together. My NPCs are designed with that pack in mind, though I also use some other custom heads as well as some of the better-looking NPC heads. However, I ran into a little problem with the head pack. I placed the wizard companion (who is an elf) in one of the likely places one might expect to find such a character, only to find that no matter which head I chose, I couldn't distinguish her from a nearby elven NPC. I opted to move her to a different location, but this will certainly be a larger problem when I create an elf-dominated area.

 

I continued working on the companion dialogue and interjections for various areas, and also decided to add a clue via one of these interjections to something rather secret that I expected no one would find.

 

There's one more companion to make, some more companion dialogue to write, some more interjections, and some descriptive text.

 

I placed descriptive DM text all around the cavern. In most cases, I used objects with descriptions to augment the visuals, but in places where there were no interactive objects, and it would not be convenient to place any, I used the unobtrusive method of sending descriptive text to the chat box/combat log. More important areas have the DM text pop up in a description box. In general, I only place this kind of triggered descriptive text in "dungeon-like" areas.

 

I also placed map pins around the cavern, which the same triggers activate when you reach them. I still have some companion bark triggers to place there.

[Originally posted 13 June 2014 - 01:34 PM]

 

I'm sure there is a thing that can alter attributes permanently until removed and I just had a look at Lilac Souls script generator and this might point you in the sort of direction to what you wanted to happen after a prison visit.

void main()
{
object oPC = GetPCSpeaker();
object oTarget;
oTarget = oPC;
effect eEffect;
eEffect = EffectAbilityDecrease(ABILITY_STRENGTH, 3);
eEffect = SupernaturalEffect(eEffect);
ApplyEffectToObject(DURATION_TYPE_PERMANENT, eEffect, oTarget);
}

Then again I don't know anything about scripting so could be completely wrong.

 

Well, I appreciate the attempt, but that is essentially the same code as what I'm using:

    ApplyEffectToObject(DURATION_TYPE_PERMANENT, EffectAbilityDecrease(ABILITY_STRENGTH, 1), oTarget);

It wore off after I rested. I suppose the game just decided on its own meaning for the word "permanent".

 

not sure what you guys are on about, but this might enlighten ........

by default an effect is applied as subtype MAGICAL
This means it can be dispelled or removed by resting. The other two subtypes are

int    SUBTYPE_MAGICAL          = 8;
int    SUBTYPE_SUPERNATURAL     = 16;
int    SUBTYPE_EXTRAORDINARY    = 24;

Extraordinary effects can't be dispelled but will be removed by resting. you'd do something like this, to gain more permanency (as per Password's code) :

effect eDecrease = EffectAbilityDecrease(ABILITY_STRENGTH, 1);
eDecrease = SupernaturalEffect(eDecrease);
ApplyEffectToObject(DURATION_TYPE_PERMANENT, eDecrease, oTarget);

But to get REAL permanency, got to use

// MAP 3/15/2009
// !EXPERIMENTAL
// Note that any changes to skill rank will NOT be lost if the character is de-leveled.
// IMPORTANT: Most usages of this will cause characters to fail 'enforce legal character' restrictions.
void SetBaseAbilityScore(object oCreature, int nAbilityType, int nScore);

"permanent" just means the effect is applied neither 'temporarily' nor 'instantly' ..... (not that that helps!)

 

By that description, Extraordinary is the opposite of what I wanted -- I would like the Restoration spell to fix it, but not resting. Would that be Supernatural?

 

yep. wiki says that any of the Restoration line removes "all magical, extraordinary, and supernatural effects that apply a penalty to ability scores" etc.

 

Okay, sounds good. Thanks, both of you.