1056 réponses à ce sujet

[Shallina]

it's possible to sleep on a bed with the prone animation and a walkmesh helper

Modifié par Shallina, 09 avril 2013 - 09:20 .

[Tchos]

I did consider showing an animation of the player sleeping on the bed, especially since I had made that sleeping Zs effect earlier, but I thought it was fine to keep it a little abstracted like this, especially since I was aiming to recreate the scene from BG. That, and of course I never liked how in games everyone sleeps on top of the blankets, usually in their clothes. Perhaps if I try a sleeping player animation in the future, I'll try covering them up with something.

As for uploading copies of my fixes, I'll have to check on the etiquette of that. It's a very minor change, and many frown on uploading copies of someone's work with such a minor change. I'll make a post in the custom content forum to poll the community.

[Shallina]

For sleeping i think a black screen is enought.

But if you want you can change the player equipement and restore it after sleeping

[Tchos]

Unequipping items on the player can cause negative effects, such as if the player is a spellcaster with gear that boost primary stats such that s/he gets an extra spell slot, and would lose it when the gear is removed. To do it during a resting would possibly be okay, as long as ForceRest is done during a black pause between the rest scene and the player being re-equipped.

However, I think what I would do would be to clone the player, remove the clone's equipment (and optionally equip some form of nightwear), and put that clone in the bed for the scene before destroying it at the end of the night. That way, there's no chance of anything going wrong with the actual player.

Edit: No, on reflection it still wouldn't be okay to do the ForceRest after re-equipping, because the lost spell slot would be blank when it was restored.  The clone idea seems much better.

Modifié par Tchos, 09 avril 2013 - 09:59 .

[kamal_]

I liked it the way it was. Also, it's much easier...

[Tchos]

I'm not changing it for this module. I'm just thinking of ways I might try it in another module.

[ColorsFade]

Shallina wrote...

For sleeping i think a black screen is enought.

How does one do this? Is this part of the MoB sleep system?

[kamal_]

ColorsFade wrote...

Shallina wrote...

For sleeping i think a black screen is enought.

How does one do this? Is this part of the MoB sleep system?

There is a stock fade to black command (it defaults to black, but you can use any color).

[Tchos]

Fading to black on rest is indeed an automatic part of the MotB rest system, as well as advancing the time 8 hours. That's what I use when you camp out to rest.

I use a ga_ fade to black script in my other rests and other times when I have time passing, but ga_fade_to_black has a built-in enforced failsafe that fades it back from black after a certain amount of time. (Its fFailsafe parameter defaults to 15 seconds if you specify 0.) Since in my conversations, the user may leave it on a particular node for any amount of time, I duplicated the script with a new name and modified it to allow me to have no failsafe. It fades back from black when the next node appears, with ga_fade_from_black applied to it.

ga_fade_to_black uses the FadeToBlackParty() function, which I think is the best one.

[Tchos]

I spent some of today giving the various creatures different loot tables using the SoZ treasure system, but I really wanted to also give some randomised crafting supplies beyond the usual "animal parts dropping from animals", and that system doesn't include such things. As a sort of temporary measure, since I didn't feel like going as far as making 2da files for crafting supplies just yet, I used an item I had created for quest rewards -- a bag/box of goodies. The difference is that where the quest reward bags have specific goodies in them, here I made a pouch that randomly picks some items from the list of crafting materials, to represent an NPC's supply of crafting goods that s/he intended to use.

I made separate bags/boxes for blacksmithing supplies, alchemy supplies, woodworking goods, leatherworking goods, and scribal goods. It's convenient to have these items drop as random loot, deferring the generation of their contents to later. The way I scripted it, these containers contain somewhere around 1-6 supplies in their theme, though in future modules I'll add the ability to set the minimum, maximum, and percentage chance through variables.

I added some entries to the baseitems.2da, because none of the "miscellaneous" items (small, medium, large, etc.) were above half a pound. Also missing from this selection was a "paper" item, for readables other than "books". Setting an item's base item to "scroll" for a simple ransom note or shopping list has the undesired effect of allowing a wizard to scribe a spell onto it, while setting it to "book" makes that note weigh a pound and make a "thunk" sound when you pick it up or drop it. I was already modifying the baseitems.2da because of the fishing system, so I went ahead.

After doing this, the toolset started throwing up error boxes saying "wrong version". I removed the 2da and things went back to normal. Comparing the new one with a fresh copy from the Data folder's 2DA_X2.zip, I saw that the difference was that the new one had quotation marks around everything (including the version number, which is probably why it gave that particular error). This is the result of having opened the 2da in OpenOffice Calc (the OpenOffice suite's spreadsheet) and saving it from there. There's probably a way to prevent that behaviour, but I haven't looked into it, since I usually edit 2das in text editors, and only open them in a spreadsheet if there are a lot of columns that don't display neatly in a text editor.

Next I had to come up with a means of turning on and off the lights in the town area (the one I can't open) without having an area heartbeat or user defined event script specified in that area. Selecting and disabling all the lights in an area, and turning them on again, was no problem (using OBJECT_TYPE, not tags), but I needed a timekeeper to choose when to do it, which normally I'd put in the area heartbeat. Instead, I added some time-checking heartbeat code to an NPC who was already running a longer heartbeat than default (12 seconds) and who would always be there, so he could act as the timekeeper without adding another heartbeat object to the game. This of course would not have been necessary if I hadn't failed to heed the good advice of others to always set each area's scripts to something, even if the scripts don't yet exist. I started doing that a while ago (and making a list of what scripts are named for each area), but too late for this one.

I think I'll have to leave the torch fire effects alone, because I don't see a way to either hide them (ScriptHidden only works on creatures) or disable them -- only to destroy them and recreate them, and I don't really want to deal with storing all of that location information. Again, this is on the docks, so it's a little late to add something like SLS.

In other not entirely sane matters, I would like to know if there is a way to change an NPC's owned conversation by script (so that when a player clicks on them, it always fires a different conversation than was initially assigned), or if that's just one of the property fields that can't be modified by script. I have a functioning workaround if it's not possible, but it would be ideal if it were possible.

[ColorsFade]

Tchos wrote... I would like to know if there is a way to change an NPC's owned conversation by script (so that when a player clicks on them, it always fires a different conversation than was initially assigned), or if that's just one of the property fields that can't be modified by script. I have a functioning workaround if it's not possible, but it would be ideal if it were possible.

Funny that you would journal that right now, because I was wondering the same thing - just ran into an issue where this would be a nice feature.

So far, my investigations have revealed nothing that allows this to work. So... I am working on the idea of using a duplicate character blueprint and attaching a different conversation to the duplicate. 

Clumsy, and violates SRP, but seems to be the only recourse right now. 

[Shallina]

You can assign which conversation the NPC will use in the StartConversation function. With custm scripting it's possible to have different convo for a same NPC, but you may need a custom on_conversation script for it.

for exemple you need to change the ligne where the convo start by something like that :

SetLocalstring(OBJECT_SELF,"convo","your_conversation");

AssignCommand(OBJECT_SELF,ActionStartConversation(oPC,GetLocalString(OBJECT_SELF,"convo")));


With someting like that the NPC will be able to start the conversation that you stored in him as a LocalString.

Modifié par Shallina, 13 avril 2013 - 06:15 .

[Tchos]

Hmm, yes. I think I could make that work. My temporary hacked solution uses a new conversation's name assigned via a local string.

Ah, yes! In fact, since I can change a creature's script set via script, that means I can change its On Conversation script to a custom one that reads the preferred conversation name from the local variable, if one exists. Or, I could keep the same scripts assigned and change the NW_C2_DEFAULT4 script itself, but that could be more unreliable if there are mods that override it.

Very good. Thank you, Shallina. You've set me on the right path.

[Shallina]

na you do your own NW_C2_Default4, like, BSSC_C2_DEFAULT4 wich is the original one where you changed the call of that function to call the convo stored in the localstring and not the one stored on the NPC panel.

Then you can change the convo of that NPC on the fly, by setting the localString whereever you wants.

For NPC with only one conversation just use the NW_C2_DEFAULT4 script for them.

[Tchos]

Right, but for what I have in mind, it's necessary to change the script set on the fly, too, because this needs to be done on a game in progress, where the scripts have already been set.

Adding a new script set to the nwn2_scriptsets.2da enabled me to switch the already-existing NPC's On Convo script to my edited version that reads it from the string.  I have it use the default convo if there's no string.  It works beautifully!  I tested it, selecting any NPC in my game, and changing its default conversation to anything else by setting the string.  Now I can repurpose any NPC on the fly.  Very happy.

The relevant section:
        if (GetCommandable(OBJECT_SELF))
        {
            ClearAllActions();
            string sConvo = GetLocalString(OBJECT_SELF, "ConvoOverride");
            if (sConvo != "")
            {
                BeginConversation(sConvo);
                return;
            }
            else
            {
                BeginConversation();
                return;
            }
        }

[Shallina]

I tried to do that and it didn't go well

Instead i used a case off with execute script call

So 3 scripts. One with a case of in the NPC panel, and the 2 others called depending the case.

[Tchos]

My way also uses 3 scripts: The replacement On Convo, a script to swap the NPC's script set to use the replacement On Convo, and a script to set the local string on the target. It also requires a 2da containing the new script set. This way, if I wanted to, I could even put these items into my override folder, play someone else's module and use the console to change the NPCs in their module, to use any conversation in their module, as long as I knew the conversation's name.

[PJ156]

Why not do this in the conversation itself? I need to do something similar in the future but I plan to simpy use integers to sort the opening strings the npc uses. I can set the integers in the module opening.

Is there a reason you went the scripted rout? I found the more scripts I have the less chance I have of debuging the darned thing.

PJ

[ColorsFade]

PJ156 wrote...

Why not do this in the conversation itself? I need to do something similar in the future but I plan to simpy use integers to sort the opening strings the npc uses. I can set the integers in the module opening.

Is there a reason you went the scripted rout? I found the more scripts I have the less chance I have of debuging the darned thing.

PJ

There's more than one way to skin this cat, for sure. 

I tend to prefer scripts. Long conversations are a code smell, to me. I don't like looking at them; they get unruly and become difficult to navigate (visually - to me). 

Tchos has a different end-goal with his, I think...

I'm glad this came up though. Because the strategies to handle this situation allowed me to fix my conversation roadblock too. 

I ended up using the User Defined Event and variables to handle this.

I attach a custom user-defined event script to the NPC blueprint along with the SpawnScript to enable NW_FLAG_ON_DIALOGUE_EVENT. 

On the spawn script for the area, when I spawn in these NPC's, I set a local variable on them which corresponds to the conversation name. The User Defined Script checks for this local variable when the EVENT_DIALOG fires (by the way - EVENT_DIALOG doesn't seem to work, at least for me, the script compiler doesn't know what it is, but the number is 1004, so that worked). 

If the User Defined Script finds that local variable on the NPC to be empty, it just fires the NPC's normal conversation. Otherwise, it uses the conversation assigned to the variable. This allows me to assign any conversation to any NPC at any time, through scripting, as long as that NPC has the default User Defined Script attached and the SpawnScript variable set (which is easy, since all I have to do is edit the NPC blueprint). 

[Tchos]

The hacked way I did it before was through the conversation itself. I used a custom token in the first node to determine the initial greeting. It works that way, yes, but I just didn't like it that way, using the same conversation for what could be a lot of different characters handling different quests.  For barks, it's fine, but anything more complex, and the debugging trouble is still there, just in the conversation conditions rather than the scripts. I think I'm more comfortable dealing with the scripts now, because I find it easier to read than checking a lot of conversation nodes. Those columns can only show so much on screen at a time.

I'll post a little demonstration of how this works, though. I really don't think any bugs are likely at this point. It works just like the normal conversations.

Modifié par Tchos, 13 avril 2013 - 06:00 .

[kevL]

int EVENT_DIALOGUE = 1004;


Tchos: i just added varname ConvoOverride to my 'default' scripts (NPC, Companion, Associate). If you're interested in simplifying the "relevant section", try this ( Untested )

if (GetCommandable(OBJECT_SELF))
{
  ClearAllActions();

  string sConvo = GetLocalString(OBJECT_SELF, "ConvoOverride");
  BeginConversation(sConvo);
}

- if an override hasn't been set, sConvo should be just an empty string (default dialog), right? but it should be tested. I also notice that in the scripts there are conditions for Petrified, Dominated, Paralyzed, etc etc; the SoZ ai uses a bitwise function for that, and it's probably the most complete ... plus a check for GetCurrentAction() might be good..


/ thinking generally

Although, granted, in the past i've used PJ's method (with the drawback of trying to sort through the logic in the convo-editor), and *will likely continue to do so**

but I always like a good hook

[Tchos]

kevL: It should work, yes. The check is probably redundant from the way the function is set up. I thought of that when I was posting the code, but I haven't tested it. Since it works as it is, I've left it in place for now.

Tsongo: I don't think I've been clear enough about under what conditions this has to work. I have a demo encoding for upload to Youtube that I think will illustrate it better.

[Tchos]

Here, I've opened one of my old saved games from the Storm of Zehir campaign.  If you've played it, you'll recognise the NPCs shown.  I have not edited this module or campaign -- no changing of default scripts, no editing of conversations...nothing.  All I did was place the three scripts mentioned above and the one 2da file into my override folder (they do not have the same names as any existing scripts), and I'm going to execute the scripts from the console, and change the conversations of the characters.


Don't disable the annotations in this video, to see my notes and explanations of what I'm doing.

So for my purposes, I would be doing this with generic wandering NPCs who were not set up for anything, or who were set up for a different purpose entirely (especially ones that share a single generic conversation with other NPCs), and giving them a new purpose on the fly, in a game in progress, using new conversations that I include in the update.  That last bit is the important part.  It has to work on a game in progress, with any NPCs, without any kind of setup or foresight such as placing speak triggers around them.  But even if the NPC were simply standing around, this method would be my choice, because it works perfectly, and is extremely simple.  The fewer moving parts, the fewer possible errors.

Modifié par Tchos, 13 avril 2013 - 10:21 .