1056 réponses à ce sujet

[Tchos]

For my purposes, the AoE is (and in most cases will be) created through a script fired in a conversation with either an NPC, an inventory item, or a placeable, which will often be in a different area than the AoE, and there are multiple AoEs in different locations, all created at that time.

I know that items can't use PlaySound directly, though I have them assigning sounds to the PC doing the clicking, which works fine. It might not be a problem to have an NPC in another area assigning actions to an AoE in the current area, but I can't say for sure without trying it.

[Morbane]

Tchos wrote...

I have them assigning sounds to the PC doing the clicking, which works fine.

Death to the Sound Ninja!!! Woo Hoo!!  :innocent:

[Tchos]

I worked some on the last planned quest conversation, which was fun. Gnome dialogue is fun to write.

The quest itself was already in place, and functioning, but there was no conversation to start it and end it.

Hooking up all of the possible nodes and assigning actions and conditions to them, on the other hand, is not fun. This time, though, I tried an organisational strategy of moving a chunk of dialogue out of the deeply-nested nodes, and into a new branch off the main node, with a kind of "header" describing what its purpose is. I then jump to the first actual dialogue in the branch as a link destination, and jump back into the main nodes as necessary.

This one's a complicated one, since it needs the option of refusal as well as a "try again later" state if you either can't afford it or don't want to do it immediately, and it also plays a part in a much later quest. It also includes lines spoken by multiple speakers.

Then I had to write a script to equip the equipment, as well as an unequip tag-based script to make sure you don't try to unequip it when you shouldn't. And also to unequip weapons and cloaks, which don't work well with the swimming animation. This is done with the consent of the player, of course, and in a safe environment, not just arbitrarily stripping gear.

This didn't work for anyone except the main PC on the first try, and I traced it to the loop that cycles through the party with GetFirstFactionMember(oPC), which in fact needs to be GetFirstFactionMember(oPC, FALSE). The "FALSE" is for the boolean "PC Only". I don't know why the default TRUE doesn't work here, since all of the other checks I've used like GetIsPC() work on all party members, so why the other party members aren't "PCs" to this function is a mystery to me.

Anyway, now it works, and that quest is finally hooked up to the dialogue. Still need to script the unequipping of the gear and the dialogue for the last part of the quest.

Elsewhere, sometimes I'm having trouble with return dialogue. When using the gc_talkto() condition, sometimes it just skips right past it, even though I'm using it in its correct but non-intuitive way to check that the NPC has not been talked to. Since I have its counterpart action on the same node, perhaps that's the problem. What is the order of execution between conditions and actions? Surely it should check to see if a condition is true before it executes any actions on that node, so there shouldn't be any problem setting the condition to true on the same node that checks for it. At any rate, that doesn't seem to be the problem anyway, because I moved the action to set the variable to a subsequent node, and it still skipped past the initial first-time-speaker node.

Modifié par Tchos, 07 juillet 2013 - 08:49 .

[PJ156]

Tchos wrote...

Hooking up all of the possible nodes and assigning actions and conditions to them, on the other hand, is not fun. This time, though, I tried an organisational strategy of moving a chunk of dialogue out of the deeply-nested nodes, and into a new branch off the main node, with a kind of "header" describing what its purpose is. I then jump to the first actual dialogue in the branch as a link destination, and jump back into the main nodes as necessary.

If I undersatnd you correctly I think I apply that strategy to the whole npc conversation for much the same reason.

I like to have a series of reactive nodes first, some generic, random hellos and, where required, the quest or PC behavior driven responses at the top. I then set up an npc node which is for holding the responses only; these I can link into from the reception(hello) nodes as I need to. This way is easier to set up and test and pays dividends when you have a complex set of conditions to track through.  

Is that what you ahve done or have you used anther format?

PJ

[kevL]

Tchos wrote

... all of the other checks I've used like GetIsPC() work on all party members, so why the other party members aren't "PCs" to this function is a mystery to me.

GetIsPC() harks back to NwN1. There's only one (1) PC there, in SP. GetIsPC() in NwN2 checks if a character is *controlled* by a player. That specific function could have been renamed GetIsPCC -> GetIsPlayerControlledCharacter ...

The problem is that us scripters get to thinking "oh so that's what a PC is" when other functions use the term, PC, a bit differently.

There's a big old thread about this and similar matters, but the confusion was never fully resolved - at least not for me until I wrote c-info.


A challenging exercise, just for example, is to write a function that takes any PC-faction member as input and outputs a string to the player(s). I wanted to do this in spellscripts so that no matter which of my buddies is targetted by a spell, i the Player get feedback no matter who is controlled at the time the spell lands. ( which reminds me i still want to muck w/ MySavingThrow() ) sigh*

[Tchos]

PJ: I think what you're describing is what I've done, but I've only done it minimally as yet, so it's not as well-developed as what yours sounds like.  This is a peek at mine, just showing two separated-out nodes that the main ones link to:
https://www.dropbox....logue nodes.jpg

Modifié par Tchos, 07 juillet 2013 - 09:56 .

[Tchos]

kevL: That makes more sense. I hadn't thought of the NWN1 connection. And thanks for reminding me about that script of yours. I saved it for later experimentation, but hadn't gotten to it. It should provide a deeper understanding of it.

Would definitely be nice to get spell feedback on all party members. Or other things, like diseases. I have a place where there's a chance for catching a disease, but if you're not controlling one that catches it, you won't see the dice rolls and other information -- just the FX and the "diseased" status icon.

[kevL]

yeh i'm Mr.Supermicro, so just imagine pausing every 100ms trying to control the right character to get the feedback

anyway I hope the output from my script is fairly easy to understand; ie, what function calls were used for readable output.

[PJ156]

Tchos wrote...

PJ: I think what you're describing is what I've done, but I've only done it minimally as yet, so it's not as well-developed as what yours sounds like.  This is a peek at mine, just showing two separated-out nodes that the main ones link to:
https://www.dropbox....logue nodes.jpg

I think we are on the same lines. I tend to attack a coversation cronologically so a simple shopkeeper might look like this.

Hello bob, good to see you finally killed those bandits (reactive to event once only)
Hello stranger I sell weapons{first greeting}
Hello bob, you back for more. {greeting general-might be random for important npc's}
HOLD 1{associated with quest 1 or module 1 or however I want to sort it - give this an impossible condition}
  blank pc node
     blank npc node
        PC questions or realated discussion.

In the end I have only ised one hold to date but there could be more. If it is a NWN1 conve you cannot easily use the two black nodes which is a pain. You still can but they show as a blank screen and the flow is lost. In NWN2 cutscene theay are the best part of the conversation as they dont show and it means that all the other lines above only link to one node.

You can then use those nodes to loop back into the conversation without testing lots of pc dialogue nodes which is very ahndy and helps the coversation to flow.

PJ

[Tchos]

Well, I don't need to give it an impossible condition, because I placed it at the bottom, past a default node that it can never get past. I have the blank nodes, but those don't matter since my link destinations jump directly to the actual content, not to the blank nodes. (These are all SoZ conversations, BTW, so that you can always select different party members for their unique dialogue options.)

[PJ156]

You're right the condition is irrelevant.

I don't do SoZ to date but I am toying with it for this module since I only have a few conversations created to date. However jumping to the content was what I was trying to avoid. What I found was, it is okay for a shop keeper with three nodes but when an NPC gets more than five it becomes hard and when they hit forty - fifty nodes it is just not tenable to link direct to the nodes.

I am going to play with the SoZ conversations tonight. You have tweaked my interest in those again. They are effectively NWN1 in format but do they fall through a blank node or would you have to click each time a blank node appeared?

PJ

[Tchos]

They behave almost exactly like the NWN1 conversations with the exception of the ability to involve your whole party, but there is one other difference I've noticed (unless I'm mistaken). If you end a conversation branch on the NPC's line, it'll present it within the box, and the player ends the conversation by clicking "End dialogue". If I recall correctly, with the NWN1 conversations if you end the branch on the NPC's line, then the box will go away and the NPC will bark the line.

Likewise, I don't believe it falls through blank nodes, and instead shows an empty NPC dialogue for that node that you have to click past. But what are you using those blank nodes for? I assume you're spacing out scripts or something. If not, then why not jump directly to the content?  I only used them so that the content starts with the right character (NPC or PC).

Modifié par Tchos, 08 juillet 2013 - 07:25 .

[Tchos]

Dealing with the gnome dialogue and attendant quest feels like clearing a roadblock. I spent the day testing it and fixing problems that I found with the dialogue and the quest conditions, as well as the unequipping script. I had to make a special exception for one of the recruitable companions, who wears a special armour, because I learned that the "never show armour" property includes helms, despite helms having their own property (never draw helmet), which I thought would override it if it's set to allow drawing the helmet. It doesn't. I experimented briefly with using a VFX for the helm before settling on the unequip script solution.

I also made the assistant a little more reactive to the quest states.

There's still the second interaction for this NPC to deal with, but since it doesn't involve a new quest, it shouldn't take as long or need as complex a dialogue tree.

I removed the gc_talkto() and ga_talkto() scripts from the conversations and returned to the way that always works -- just manually checking and setting a local variable. It should work with the general scripts, but maybe later I'll just make my own.

As shown in my custom placeables thread, I also made a new placeable of a rack of pamphlets, for both decoration and function.

I'm also really glad I made a custom item type for sheets of paper as mentioned a month or two ago, because a lot of my quest items are papers, and I didn't like using the "book" item type for a simple sheet of paper. Wrong weight and sound effect, for one thing. And using the "scroll" type is problematic since wizards can scribe spells onto them, which you don't want them to do to your quest items!

Something that's somewhat exploded lately has been my use of custom tokens. I started using them early on for the taverns, but I've started using them extensively to provide running counts in the journal entries for quests, as well as in the perception scripts to allow NPCs to call out barks that incorporate information about the PC they're seeing (be it gender, race, class, or name if they know the PC), and most recently to allow the NPC to mention the current number of members of the player's party in a conversation.

Like the other important data in my module, I keep a list of which custom tokens I'm using, and what they're for.

[Tchos]

Today I tackled another, simpler item from my to-do list, which was to add the captain of your rented ship to the cabin after a certain event, and give him an appropriate conversation for it, referring to certain quest stages and giving certain options. I know, very cryptic, but it's more of a progress report than a spoiler-fest. Just saying the to-do list is getting shorter.

There's actually already another conversation with the captain in place while on the overwater map, but I didn't need to place an NPC for that.

I also added a necessary limitation to the Hearthstone of Divine Recall. It will not work underwater, or across large bodies of water. I did this to avoid breaking quests that use area transitions to update the journal stages. Logically, as well, you shouldn't teleport back to town while you're at sea, and leave your boat out in the water. Though I suppose you might, if it were a matter of life and death.

I wrote another simple utility script, again for the docks. This one simply reports the tag and location vector of whatever waypoint is nearest to the player's current location, because I didn't see any console command for making waypoints visible in-game. Yes, it really is easier to write these scripts than to get that area to actually open in the toolset. I also had it fire a VFX at the location of the waypoint so I can see exactly where it is. Since the town area is covered liberally with waypoints, chances are there's a waypoint close enough to where I want to spawn something, or send an NPC to walk to, or for something else to happen at. For more precision placement of things, of course, I'll still be using the vectors.

I had trouble getting an inventory item to fire a conversation on activation. I tried a few ways, and one way almost worked, except that it only showed the first line of the conversation as a bark rather than actually running the conversation. I found a few forum posts about how to do it, but none of the suggestions worked. It didn't strictly need to be a conversation, though, so I just went about it in a different way. Still, it should have worked.

Well, I ended up trying the code from the IP Speaker include file, starting with CreateIPSpeaker(). The trouble with this is that the scripts that fire throughout that process require some other object to be the "speaker". It's not like the way I've used ipoints before, which was to substitute for a speaker -- in other words, speaking directly to the ipoint as if it were a particular NPC, so that the conversation wouldn't be broken if the NPC dies or is destroyed. It seems that the IP Speaker scripts are solely for the purpose of making sure a conversation between the PC and some object fires, and then it goes away.

But since I was having such trouble getting the conversation to fire in the first place, I kept at it. But nothing was happening. I'd activate the item, see the debug text saying the script was firing, and no conversation would start. I dug around in the scripts for a long time before determining that it had a special section dealing with the PC. It didn't take a PC object parameter. Instead, it got the PC inside the script where it starts trying to speak, and normally, that's GetFactionLeader(GetFirstPC()), except that it has an if statement looking for a global string CAMPAIGN_STRING_CUSTOM_IPSPEAKER, and if that exists, then it doesn't use that function, and instead looks for another script to execute to determine the PC. Why?

Okay, so it's a campaign string. I traced it to something I could do, and found in my module load script a place where it specifies the name of the script. Naturally, I didn't have such a script, and so the IP speaker was just failing. So I went into the SoZ campaign folder and found the script and put it into mine. After that, it got a little further before stalling, telling me that oSpeaker was invalid.

Since it's an inventory item that starts the conversation, the player could be anywhere when activating it, and so the "speaker" had to be something that would always be present -- like the inventory item itself. But that doesn't work! Why, I don't know. Because items just can't talk? Because the scripts look for the nearest object with that tag, and inventory items aren't near? Who knows. And the PC doesn't seem to have a tag, and since the scripts are all set up to get the object by its tag, it had to have a tag.

So I decided to spawn a second ipoint manually, to act as the speaker for the IP Speaker. I scripted the activation of the item to create a blank generic ipoint. The conversation still wasn't firing! I enabled the debug text, and it kept telling me the speaker was invalid.

Many tests later I tried spawning a wine crate instead of an ipoint, and surprise surprise, it worked! The conversation finally fired, between me and the wine crate. Interestingly, the wine crate blueprint is set to static, but I guess when you spawn something by script, it isn't static, despite what the blueprint's set to.

So I compared the wine crate and the ipoint blueprints to see what the difference was, and aside from the static setting on the wine crates I didn't see anything different. I went to put the ipoint's resref back into the script, but this time I copied it from the field instead of typing it like I had the first time, and I saw that there's a space at the end of the resref. So it wasn't spawning because I didn't include the space in the string.

I put the space into the string, and also set the ipoint's first name to the item's name so it wouldn't say "Ipoint" in the dialogue box, and it finally all worked.

Then I tried actually doing the quest, and found that somehow, some way, firing this conversation breaks the quest. The updates don't happen, and I don't know if it's because the AoEs aren't getting created at all, or what. There's nothing in the conversation that affects those things at all. The conversation does nothing but destroy the ipoint that's acting as a speaker at the end of it. I can start the quest, get a couple of updates just find, but as soon as I fire the conversation, no more updates. It's a mystery. So I figured out how to get the IP Speaker working, but I can't use it here.

The whole purpose of using a conversation was to make a rather long bit of text be broken up into sections, rather than as a long document in the item's description. But having the quest work at all was more of a priority, so I just abandoned the conversation and put it as a description.

It wasn't a total loss, though, because I needed to figure out the IP Speaker system to use for the module's epilogue slide show.

[Tchos]

Today I finished the gnome dialogue. That was the second to last major step preventing the main quest from being completed. I just need to rough out the extra boss fight, and then I can send the module out to a few people who asked to beta test it, and polish up the remaining bits while they do.

The beta will not include the epilogue scene, a few side quests, or all of the companions. Three companions are included, but their dialogues are not finished -- just functional.

It turns out there was more I needed to do before I could release the beta test. I had left the sahuagin in an unfinished state, and I needed to create their proper classes, looks, powers, properties, and inventories. The looks are unfortunately limited to colour changes, scaling, some armour pieces, and weapons. Armour displays only as a colour change on the creature, which looks bad, so I have them set to not show their armour. There are no head pieces, which would help a good deal in differentiating them, but there are some good shoulder pieces in the form of turtle shells that some of them can wear.

Source material claims that sahuagin priestesses undergo a ritual that leaves them yellow in colour, so this is how you can tell which ones they are. There is no specifically female model, though, which is unfortunate considering the prominence females have in their society, as their clerics are implied to all be female. Kuo-toas, on the other hand, seem to have a mixed population of clerics, despite the source material (Drow of the Underdark) only outlining a female cleric (called a Whip).

Anyway, I also created specialised loot tables for these creatures, with variations by class, with a couple dozen new items appropriate to their society and what they value as described in the manuals.

Also wrote a user-defined event script to apply certain behaviours to the sahuagin in response to player actions, which are described in the source material.

I finished the epilogue script after all, and wrote the epilogue cinematic (one of the only places where I use cinematics), though it still needs slide images to show during the text. It does have a shortcoming in that it assumes that your character would opt to be recognised as a hero, when some characters may prefer to slip out of town before the fanfare begins.

Now for a test to see if it's ready to send out.

[kamal_]

Tchos wrote...

It turns out there was more I needed to do before I could release the beta test. I had left the sahuagin in an unfinished state, and I needed to create their proper classes, looks, powers, properties, and inventories. The looks are unfortunately limited to colour changes, scaling,

I have these guys sitting in my toolset, and I was playing around with their coloring, but they seemed to have a green base, limiting the tint options. Did you give them a more tintable base?

[Tchos]

No, I'm working with the greenish base. It's not so bad, since you can cancel out a minor tint like this with enough of its complementary hue, without it turning too dark. Getting a yellow tint is no problem.

[Tchos]

In my full run-through playtest, I amassed a huge list of bugs to fix. The first was somewhat amusing, as I was surprised to find a sahuagin high priestess waiting for me at the office of the harbourmaster, because I had placed one in there just to check her tinting, and must have had the area open when I did a full save to save the blueprints. I also found in that instant that the plot-essential harbourmaster NPC was level 1 and not set to plot.

Other issues involved things like one companion not gaining XP, despite his initialisation dialogue actions being exactly the same as the others, while a different companion was not dismissed from the party like the others are when you choose to edit your roster.

More things like conversations not showing the correct node depending on quest stages, and one spot where I missed a loophole that could cause a quest not to complete. I think I've taken care of those now.

The creatures that I created before I started using the SoZ loot system are now a bit embarrassing because they all drop the exact same things. So I spent a few hours making appropriate random loot tables for them, with a lot of custom loot, and also giving them the new random perception and death barks.

I somehow either forgot to assign a deathscript to a certain NPC, or the script was somehow lost, which activates an object that the player should be able to interact with.

During an important conversation, party members are preemptively attacking creatures that should be non-hostile. I retooled the script to use the ginc_group functions instead, so we'll see how that works. Needs another run-through.

[I_Raps]

Tchos wrote...

The first was somewhat amusing, as I was surprised to find a sahuagin high priestess waiting for me at the office of the harbourmaster, because I had placed one in there just to check her tinting, and must have had the area open when I did a full save to save the blueprints.

Things like that seem easy to overlook.  In one of the areas of the Halloween SOZ Mod, there is a Destructificator laying on the floor.

[Tchos]

I do have a Destructificator lying on the ground, but it's in a testing area that can't be accessed through the normal game.

I could be wrong, but I think the function notes may be wrong for GetLocalInt().  It claims that if the object doesn't exist, then it returns 0.  But I had a door with an int of 1 on it, and I was depending on it returning 0 if the door were destroyed.  But the condition on the conversation that checks that was behaving as if the door still existed and had a 1 on it.  I reorganised the conversation to work differently so that it doesn't matter, but that was annoying.
 
Using the group functions fixed the other problem with the companions attacking the not-yet-enemies.  I had to read through how the scripts were working to determine that group assignments persist outside of the current script.
 
I've fixed almost everything else, except that my barbarian companion still isn't gaining any XP, while the others are.  And they're all given the same amount of XP when they're first added to the roster, although I tried giving him a slightly higher number since it wasn't working.  Still didn't work.
 
Need to do another runthrough to make sure my other fixes work.

[kamal_]

My buglist from Path of Evil exists on a wiki site. It goes back to before release and is highly amusing for me. There were several thousand bugs that got fixed.

[Tchos]

Alas, I've been deleting them from my list as I fix them, though after release I would expect to maintain a version list.

[Tchos]

While testing again, I reached the cave, only to find the game constantly crashing when I approach a certain spot. That did not bode well. I determined that there was a trigger around that spot, so I tried removing it, but it didn't help. Next, I determined that it seemed to happen as the sahuagin were becoming visible, so I moved them further away. This time I was able to go into the cave further before it crashed, so I disabled their spawns. Once I did that, the cave no longer crashed.

So something's wrong with the sahuagin. Possibly something to do with the new script I placed on them, or possibly an error with the loot tables.

First I'll try disabling the special script, then I'll try disabling the loot. If it's the loot, I'll have to do a lot of checking. It also might be only certain sahuagin crashing it, so I'll try spawning them one at a time.

[Tchos]

After setting up a conversation so the I could spawn each of the sahuagin types at will, I found it was crashing on the high priestess. I traced the trouble to the visual effect I had placed on her. It displays in the toolset, but after removing it, she no longer crashed the game. I'll put the custom script back on them and see how that works. Luckily, I didn't get as far as needing to adjust the loot, though now that they're not crashing, I see I do need to lower the percentages of their drops.

I had to add another 2da to the hak, this time being vfx_persistent.2da, because I needed a blank AoE larger than the default 5-unit custom AoE. There's some very interesting information in that 2da file, and I can see many new possibilities in using it, but for now I just created a blank 10-unity AoE with no specified scripts that I can manage through my scripts, even though I should be able to use any of those and override their scripts. The function doesn't include changing their SEFs, but I could probably use a different function for doing that after I create the AoE. Simpler just to have a blank one to start with, though. I could also use a 15- and 20-unit one for later.

This one, at least, didn't give me any problems.