1056 réponses à ce sujet

[Tchos]

It's because the NPCs on which I would be using this don't have their own individual conversations. They all share a generic conversation (the "commoner" conversation), and I want to select one of these commoners and turn it into a fully-fledged NPC -- changing its name, description, tag, behaviour, etc., and give it a conversation of its own (just one, not different ones for different situations).

Other than that, it may just be a matter of personal preference. The alternative is to put a lot of conditions in that shared commoner conversation to launch entirely different dialogues for each one that I turn into a full NPC, and that would become quite a headache to manage. Quest conversations can be convoluted enough without using the same conversation for different characters with different quests.

[ColorsFade]

Tchos wrote...
Quest conversations can be convoluted enough without using the same conversation for different characters with different quests.

In my limited experience with the toolset, I have found conversations to have the highest potential for scope-creep and over-complication. Anything that reduces that and keeps conversations simple is a win in my book. 

[Tchos]

I've been splitting some of my time between this and dealing with some placeable conversions (with permission). This is a bit tricky, since these particular plugins don't work in Gmax, so I had to download a 30-day trial of 3ds Max, which puts a limit on how many placeables I can convert to NWN2 (whatever I can do in that time). I've finished 43 so far, but that's for another thread, when I'm ready to announce it. Some of them are useful for this module, though.

But back to BCoCC news, I also made a new vertical hanging vine placeable for the undersea cavern, to accompany the stock vine placeables. Not sure how well you can see them in this screenshot, and the lighting removes a lot of the placeable's colour. The icicles seen in this screenshot near the middle top need to be retextured to be stone instead of ice, since they're supposed to be stalactites.



Here's another in more neutral lighting.



I also tackled a complicated quest that I'd been putting off because of its large number of variables and possible solutions. As it turns out, I needed to reference a door in the unopenable docks area, but unfortunately I hadn't given it a unique tag. Not really a big deal, since I can just get the nearest door-type object to the waypoint, and that's the one I want, but it meant I couldn't use the ga_set_locked() script, since that script goes by tag only. That's fine, though, because I had more things to do via script in this spot that there aren't any ga_ scripts for, so it wouldn't really have saved much.

One problem I came across was that I can't seem to get a cloned creature (created with CopyObject(), with no change in tag) to follow the waypoint set of its original, who walks waypoints using the stock waypoint-walking code. The clone just stands there, even after nudging him, talking to him, going to a different area and coming back, and waiting around from a distance watching him, even if I throw in a ForceResumeWWP() command. I imagine it's something to do with initialisation and the "WWP controller" that the default system creates. I'd try spawning it instead, except that this is a Docks character without a blueprint, so I thought the scripting approach would be more convenient, if not for this issue.

Modifié par Tchos, 18 avril 2013 - 11:04 .

[Dann-J]

There are a few of hoops you have to jump through to get creatures to restart using walk waypoints - none of which I can remember off the top of my head.

In Isle of Shrines there is a dwarf in the temple of Dugmaren Brightmantle who starts off static and later begins to use his walk waypoints. The OnSpellCastAt script I used to get him to start walking them should contain all the necessary functions.

It'd probably be faster to consult the Walk waypoints thread.

[ColorsFade]

Tchos wrote...

One problem I came across was that I can't seem to get a cloned creature (created with CopyObject(), with no change in tag) to follow the waypoint set of its original, who walks waypoints using the stock waypoint-walking code. The clone just stands there, even after nudging him, talking to him, going to a different area and coming back, and waiting around from a distance watching him, even if I throw in a ForceResumeWWP() command. I imagine it's something to do with initialisation and the "WWP controller" that the default system creates. I'd try spawning it instead, except that this is a Docks character without a blueprint, so I thought the scripting approach would be more convenient, if not for this issue.

I ran into a similar problem Tchos. I think it's an engine issue.

I had spawned several guards around town and had a set of walk waypoints scattered about, all named like WP_town_guard_1, etc. I meant for the guards to traverse these. Unfortunately, they wouldn't. The engine seems to have issues when creatures with the same tag have to walk waypoints. 

The solution was this: I had to spawn each one of them with a unique tag (easy to do in a loop, append the integer value to the tag). But before spawning them, I had to set WP_TAG variable on the blueprint for the guard. Thus, each guard has a variable on them that looks like WP_TAG=town_guard, and the waypoints are named WP_town_guard_1, etc. 

Once I did that, and ran the spawn in script, they all started walking the waypoints. So WP_TAG was my savior. 

Since that's a local variable on the creature, I am guess you could assign in after (wouldn't have to be assigned on the blueprint). Worth a try. 

[Tchos]

Dann: I'll check that thread and/or your module if CF's suggestion doesn't work. One thing I should mention is that I have a character in here that starts off static and then switches to walking waypoints -- the tour guide. I made her also stop if the party gets too far away, and start up again once the party is nearby. But using the same code on this cloned NPC didn't produce the same results.

CF: I'll give it a try, though I do have numerous other NPCs that walk a single set of waypoints by having their tags the same, and not through the WP_TAG variable. I'll report my success or failure.

[kevL]

The WWPController uses Set/GetLocalObject ( so it doesn't matter if only the tags are the same -- the WWPC needs to be initialized with a specific creature (ie. not a clone* ))

i didn't trace why tho, just glanced through 'x0_i0_walkway' ..... Looking a bit further, the WWPC is stored on the creature as a LocalObject, and at least when bKickStart=TRUE it needs access ...


-> so, back to spellscripts.

* not sure why a clone wouldn't work, but have noticed that local_objects tend to disappear in cases like this

Modifié par kevL, 19 avril 2013 - 01:07 .

[Tchos]

I looked at the code for the local object bits, and found the initialisation function there.

Setting the variable on the NPC to the tag override method of walking waypoints did not help, nor did me using the initialisation function on the newly spawned clone, which from reading the code seems like it should set it to use the controller, or create a new controller if one didn't exist.
 
So instead I'm approaching the problem from the opposite direction.  Instead of spawning a replacement clone out of sight and sending the original off to perform the task, instead the clone will be sent to do the task, leaving the original to continue walking waypoints.  I know it may sound strange to have two copies of an NPC next to each other, but these are uniformed guardsmen with helms, so they look alike anyway.
 
So I have the new guard walk up and ask what's going on, and the original gives him an order, and the clone salutes and goes off to do it, and the original continues walking the waypoints.  Probably better this way than the other way.  Moving on...

[Tchos]

Considering the possible causes of a problem posed by JonnieRS in another thread prompted me to check something in a conversation file, and solved a nagging problem I was having. I have an NPC who speaks barks on a heartbeat, but who is only supposed to speak those barks at a certain quest stage, and he was speaking them all the time.

The heartbeat calls a separate dialogue file from his main one, using SpeakOneLinerConversation(). I had a condition in the dialogue file using gc_journal_entry to check for the quest stage. The problem was that gc_journal_entry was not appropriate for a bark file, since as all conversation conditionals do, it defines the PC as PC Speaker. In a bark, there is no PC Speaker. This was creating a conditional result that always fired the barks.

I moved the check to the heartbeat itself, where I could define the PC more appropriately. I should have put it in there anyway, since it allows an earlier abort.

Since I've been getting more Gmax experience, I went ahead and fixed that tilted beer stein, so now it sits properly on a table.

Modifié par Tchos, 25 avril 2013 - 12:44 .

[Tchos]

I made another effort to open the docks area, and after 4 tries, I managed to get it open. I seized that opportunity to apply area heartbeat, area user defined, and area exit scripts to it as I should have done in the first place. Next I placed the fishmonger table and a barrel of fish (from my Witcher placeable conversion project) near the fishing trainer. Now she actually has visible product to sell!



I was in the process of preparing to replace the placed city watchmen with spawned blueprints when the toolset froze up, ending that session. I saved and backed up before each new task.

I at least got one city watchman blueprint which I can use to replace any of the placed instances, but I didn't get the tags of the waypoints they're posted at and the tags of the patrollers, so if I want to do that, I need to write a script that I can fire from the console to report the tags of any nearby waypoints to where I'm standing. I probably won't do it. I was just thinking I could improve the performance of the docks area by changing most of the wandering NPCs to be controlled by a single area heartbeat instead of each running their own heartbeats.

At any rate, since I now have full area scripts on the docks, I was able to apply a script to fire user defined events on each day/night transition, and/or hourly. I used this to turn off all the lights in town during the day, and turn them on again when it gets dark. This seems to improve performance.

I did more work on a quest which involves some placeable manipulation. I really like those, myself, enough that such things are part of my design philosophy. Originally, I was just going to handle it through conversation, and I had it initially set up that way, but I changed it around and made it much more satisfying, in my opinion, with a more reactive environment with VFX and sound effects and things happening in response to your actions. I made sure it was completable with any kind of character, unless you actually have a negative value for a certain skill. Not likely at level 10, I think, and having an average-sized and varied party should make that a negligible risk.

I ended up writing a couple more scripts for it, and expanding one of the existing scripts to allow me to specify sound effects and animation playing when you use an object, where before the animation was hardcoded and there was no sound. I made sure to include defaults so that the script would perform the same way if you didn't use those variables for places where I had already used it in other areas. I really like all of these general-purpose scripts, where I can use them in such a wide variety of situations and have them do different combinations of things using the local variables.

In between this, and the placeable conversion project, I'm also playing other games, and finding all sorts of gameplay ideas in them that I'd like to include in future modding works.

[ColorsFade]

Tchos wrote...

I did more work on a quest which involves some placeable manipulation. I really like those, myself, enough that such things are part of my design philosophy. Originally, I was just going to handle it through conversation, and I had it initially set up that way, but I changed it around and made it much more satisfying, in my opinion, with a more reactive environment with VFX and sound effects and things happening in response to your actions. I made sure it was completable with any kind of character, unless you actually have a negative value for a certain skill. Not likely at level 10, I think, and having an average-sized and varied party should make that a negligible risk.

Placeable manipulation is cool. Just having a semi-reactive game environment is worth the time investment, I think. I'm anxious to play your mod Tchos just to see some of this stuff you're doing. 

The VFX are fun to play with... I've been using a few here and there for scripted events. It just makes things more lively, IMO. I'd much rather invest the time to script some VFX into an encounter instead of write dialog telling the player "you see...." or "you notice". 

Always fun reading your updates man. 

[Tchos]

I spent a long, long day making a better standalone lighthouse for the module, then UV mapping it, and then texturing it.  I built it out of cylinders and cubes, sized and tapered (from scratch, though I did use reference).  Oh, and two doughnut shapes, for the railings at the top.  After making one set of thin vertical wooden pieces from cubes (for the windows), I found afterward that I could instead make a cylinder with only 3 sides, saving a few polygons. I did that for the second set of vertical pieces on the railing.
 
I decided to leave off the door and windows, since I had already been doing it with placeables in the toolset.  I think it looks better than the previous one I had made out of parts.  The main body itself could use more detailing in the middle area, like some cracks and shading around the window areas, and the texture is a bit too enlarged, making it look smaller than it should look, but I think it's done for now.
 
Gmax reports that it totals to 790 "faces", which may or may not be the same as "polygons".  Obviously, I'm new at this, and don't know the proper terminology.  I'm not sure how many polygons is a good number to shoot for, but I see that the similarly-shaped and sized city watchtower model from the vanilla game is 938 faces, so I think I'm fine.
 
I also notice that some of these stock city pieces are rather inefficiently designed in terms of UV mapping, leaving over half of the texture map entirely empty, which could have been used for better quality textures.
 
I think I can actually make a VFX for a rotating light beam coming out of it, too.
 

[-Semper-]

looks good, but in comparison to the door the railing is way too big.

Tchos wrote...

I also notice that some of these stock city pieces are rather inefficiently designed in terms of UV mapping,
leaving over half of the texture map entirely empty, which could have been used for better quality textures.

that's because the textures are modular to give enough variation for re-usage. with a modular texture your model only uses specific parts of it, but the texture itself can be used for different props without noticeable repetition. that keeps memory footprint small, and is very often used for environments.

a different approach are textures with non-square resolutions like 512*1024 or 1024*2048. there you can use clever tiling techniques with just your uv map, instead of splitting your poly to do it manually.

Modifié par -Semper-, 17 mai 2013 - 03:49 .

[Tchos]

Hmm, I'll change that railing. I should have brought a human-sized reference object into Gmax. I'll make it about 40% of its current size. It's sized to approximately match the city watchtower, which means for the size I want it here, I'm scaling it 300% in the toolset.

I've used non-square resolutions for some of my new placeables, too, but could you explain more about the clever tiling techniques you mention (or link a reference?)

I also know of modular textures, and what you describe is good, but I'm not sure we're talking about the same thing here. It doesn't seem to be what they're doing in certain placeables that I was looking at, though I know they are in others.

In these, they're not using the same texture for multiple items and just leaving some of the texture map unused in one models versus another model -- they're using separate textures, with nearly the same content, but completely black space in over 50% of some of the versions. I think this should have been a single texture being used by multiple placeables. (Such as PLC_BC_HOUSE01 vs PLC_BC_HOUSE07.)

In a couple of cases, it looks more like it's just the result of using a standard size of textures, to keep the details at a consistent scale, even when it results in wasted space. Looking through the plc_bc_ line, I see some old versions of textures where they changed them to be tintable, or in one notable case, they actually got rid of the wasted space I'm talking about, between PLC_BC_MAUS1_OLD and PLC_BC_MAUS1 (which was then made tintable in PLC_BC_MAUS2). I interpret that to mean it was a recognised inefficiency in some cases, and was corrected.

[-Semper-]

i guess those old textures of your example are just left-overs of the time where obsidian created the textures. they used a 1024k template and filled it with all the texture parts they needed for a given set of props. in the case of the mausoleum they just rearranged the parts to fit into a 512 texture.

but this is also a very good example to show how tiling can be used.

in the first picture i set the tiling to 4 and marked the seams with the red border. now if you've to texture an elongated wall you have to cut it manually into different parts to fit the texure tiling. just imagine that your wall is 4 times longer than the specific texture part, so you can't uv this single part to the whole wall because of stretching. therefore you have to cut your wall into 4 identical segments, and stack them within the uv map. the green border marks the separated uv islands of the wall. this turned your 1 poly wall into a 4 poly wall just because tiling.



in the second pic i rearranged the different parts of the texture to use the tiling to my advantage - it's just an example and i did screw texture dimensions (power of 2, mipmapping, blah... you know what i mean ). now if we take our wall from the first example you could simply stretch the uv island of the single poly out of the uv border, and everything will be fine because of the tiling. your wall could be as long as you want, and you could play around with the tiling without the need to cut it.

rectangle textures are just perfect for environment texturing where modulation is key. this also works with square textures but you'll have to sacrifice too much space. it's only important that the parts of your texture are tileable so that there's no visible seam between them.



ps: i don't know if nwn2's engine supports non-square textures

Modifié par -Semper-, 17 mai 2013 - 10:17 .

[Tchos]

-Semper- wrote...
ps: i don't know if nwn2's engine supports non-square textures

It does.  I used a 512x256 texture for my "Caution" sign in the lighthouse's fuel room, a 256x128 texture for an envelope, and a couple of 512x1024 textures for other things.

-Semper- wrote...

now if we take our wall from the first
example you could simply stretch the uv island of the single poly out of
the uv border, and everything will be fine because of the tiling. your
wall could be as long as you want, and you could play around with the
tiling without the need to cut it.

This example opens my eyes to a different way of handling the texture of the lighthouse body that may correct one of the problems I mentioned in my first post on the subject about the texture being too large in that area.  I'd just have to carefully blend the main body of the lighthouse with the top and the bottom, which have detailing textures on top of the white stone.

[Tchos]

I spent a day going through the other 27 areas that, unlike the docks, can be opened without crashing the toolset, and both took note of their area tags and any existing area scripts, and added references to nonexistent scripts in the rest of the area script slots, for future contingencies.

It wasn't until I started doing this that I finally understood something that had eluded me since the beginning, regarding areas and their tags. I had been using the GetArea() function in my scripts, but that's a roundabout way of getting the area by checking an object and returning the area the object is in, so I didn't see why I was having to enter a tag on my areas when the function didn't even use the tag. I didn't understand that an area itself is an object, and so I should have just been using GetObjectByTag(), using the tag of the area.

I also wrote a little generic activation script so that I could have a single item that I could drop to start a new quest. That was the plan, anyway, but I can't really make it a single item, because each one needs its own description and icon, so it's more of a template than a generic multi-use script. But the idea is just to have a script in place to help me add quests in other ways while you're out in the field.

Doing more work on the undersea cave, and I needed some primitive stuff for decoration. Now, I have to be careful with these two races, the kuo-toa and the sahuagin (plural and personal forms of "kuo-toa" vary depending on sourcebook.  I see "the kuo-toa", "kuo-toas", and "kuo-toans"). Neither race is unintelligent, as I'm sure is known to more experienced DMs than myself. They typically have above-average intelligence (average 13 for kuo-toas and 14 for sahuagin). Sahuagin are described as building cities, having barons and kings, and strong communities. However, sahuagin are water dependent and can't be out of the water for longer than a short raid on coastal villages, and this module does not show their underwater communities. Thus, there will be relatively few sahuagin in this cave, scouting around, with out-of-water bases and camps that are hastily and crudely made.

Kuo-toas, on the other hand, are amphibious, and are described as living on dry land in places with pools for recreation and spawning, so they do indeed have housing that the player will see. They're described as building great temples to their god Blibdoolpoolp. Despite their intelligence, though, they're also described as insane and fanatical, so this should be reflected in their architecture and settlements. "What goes on inside the inhuman minds of these cold-blooded creatures defies contemplation, and what ancient horrors they consort with in the deepest chasms of the world are better left unknown." (Description of kuo-toas from Drow of the Underdark.) So, mad devotees of Lovecraftian horrors. And, of course, kuo-toas and sahuagin hate each other.

What I'm trying to find is information on what the kuo-toa temples look like or what materials they're made from. Given their fanatical leanings, I imagine the best of their work would go into the temples, to the detriment or exclusion of their common dwellings. They also raise their young in pens, sorted by age and ability, after they're old enough to leave the spawning pools. For the information, I'm referring to Drow of the Underdark, Underdark (campaign accessory), and the Monster Manual. I also have Gary Gygax's module D2: Shrine of the Kuo-toa on hand, which I haven't read through yet, but which looks like it has some of those living arrangement and architectural descriptions that I want.



Anyway, I made some standing torches of a sort I didn't see in the toolset. Three variations: one relatively straight, and the other two increasingly crooked. Should provide a good variety when combined with rotations, sizing, and sinking into the ground. I also made a larger version of the torch fire VFX, since the stock one is too small and doesn't completely cover the combusting region.

Modifié par Tchos, 26 mai 2013 - 03:46 .

[Tchos]

Today I examined the Legends Banter scripts to see how Marshall was handling the On Perception barks. Most of the plugins rely on a database, since they're for a persistent world, and this is one of them.

The way it works is to leave the default perception script alone except to add a line to fire another script, which checks what kind of perception event happened, and picks a line from a database to bark in response to it.

I combined the necessary functions into one script to use to replace the default perception script, which optionally fires the default at the end of it. I changed the database dependency to instead fire conversation files, where you can put whatever conditions or randomness you want. I also added a couple of variables to the list of variables you can put on the NPC, to control talk volume and whether to fire the default.

In my tests, it seems to work fine. I expect Shadow Thief: Crimmor has a much better-developed perception system, but I think this is sufficient for my needs. It fires different conversations if the NPC sees you, or hears you but doesn't see you, or when it no longer perceives you.

Now, I've heard here and there that anything you put in a perception is risky and may not fire, but I don't know what sort of things that applies to. One thing I was thinking of was having a group of NPCs gathered together with a nearby ipoint controlling their talking idle animations on a heartbeat, perhaps with bark strings as well. On perception, I would destroy the ipoint so that they would no longer use the idle animation or speak any more barks, and they would speak one battle cry bark and engage the PC in combat. Any reason why that wouldn't work?

[Dann-J]

The main problem with a perception script is that it fires when a creature enters perception range, but won't fire again for that creature unless it leaves perception range and comes back again. That's fine in some instances (such as your bark-on-perceive), but isn't much help if you want to detect changes in what a perceived creature is doing while still within perception range.

I tried using perception scripts for aquatic creatures (mostly sharks) to detect whether a creature they're attacking (or heading towards to attack) is still in the water. Unfortunately once they locked on, the perception script didn't fire again, so they happily left the water and pursued targets onto land. If you entered perception range while on land, they also failed to react if you entered the water (they remained neutral when wandering and not attacking so companions wouldn't take pot-shots at them, and only turned hostile when a valid target presented itself).

I ended up using a heartbeat approach instead, coupled with triggers wherever you could leave the water. Their HB made a constant search for valid targets (detectable creatures within perception range who were wading in water), which turned them hostile when required. Their HB continued evaluating targets, breaking off the attack if the target left the water and turning them neutral again. The shallow water triggers helped to abort the attack in between heartbeats (with a splash of water for good measure).

[kamal_]

DannJ wrote...

The main problem with a perception script is that it fires when a creature enters perception range, but won't fire again for that creature unless it leaves perception range and comes back again. That's fine in some instances (such as your bark-on-perceive), but isn't much help if you want to detect changes in what a perceived creature is doing while still within perception range.

I tried using perception scripts for aquatic creatures (mostly sharks) to detect whether a creature they're attacking (or heading towards to attack) is still in the water. Unfortunately once they locked on, the perception script didn't fire again, so they happily left the water and pursued targets onto land. If you entered perception range while on land, they also failed to react if you entered the water (they remained neutral when wandering and not attacking so companions wouldn't take pot-shots at them, and only turned hostile when a valid target presented itself).

I ended up using a heartbeat approach instead, coupled with triggers wherever you could leave the water. Their HB made a constant search for valid targets (detectable creatures within perception range who were wading in water), which turned them hostile when required. Their HB continued evaluating targets, breaking off the attack if the target left the water and turning them neutral again. The shallow water triggers helped to abort the attack in between heartbeats (with a splash of water for good measure).

I also used custom heartbeats calling a custom perception script combined with a trigger for Crimmor, so npcs will only talk to you if they can perceive you, and no perceptions through walls and such because the pc had to be in the trigger of perceptable area.

No need to reinvent the wheel if this is needed for something in Candle Cove, I can provide the scripts or you're welcome to just grab them.

Modifié par kamal_, 28 mai 2013 - 02:04 .

[Tchos]

To be a little more precise, there is something in the perception that does fire again even if you haven't left the perception area and returned.  When I sneak around the NPC with high listen skill, he says "I hear you", and while I'm still in that same range, if he happens to succeed with a spot check, or I unstealth, he'll say "I see you."  Additionally, when I use a Dust of Disappearance while standing right in front of him, after he has already spotted me, he says "I can't see you anymore."  (These are the messages I put in the conversations I used for this test.)

[Tchos]

An illustration of what I mean:

[Lugaid of the Red Stripes]

Tchos, since you inspired me to go figure out the on-chat event and listening patterns, I thought I suggest you look into that for adding in those ambient barks. Basically, you just run a script off the module or area heartbeat that orders the PCs to emit a particular chat. Then your NPCs have their listening patterns set to respond to the PCs' chats. (You can script in random delays to offset the responses from the heartbeat event.)

The main issue I'm thinking of is that if you base it on the on-perception script, then the barks will only happen once, and then when the player is probably not looking at the NPC (they may even be offscreen, depending on the perception distance). With the chats provoking the barks, they can happen repeatedly, and when the NPC is closer to the PC and thus more likely to be seen by the player.

Additionally, it's easy to code in multiple chats for the PC, each of which may provoke a different sort of bark from the NPCs. Drawing a weapon, casting a spell, or even opening a door may each have their own chat line. If you think about your particular plot, you could even think of a simple set of categories to evoke appropriate responses from NPCs. For example, one sort of response when the PCs are new to town, another when they've been battered and dirtied up by fighting, another when they're greeted as heroes, maybe others for when the townsfolk flee in horror or turn their backs in disgust.

[Dann-J]

It seems that each creature stores a list of other creatures perceived, and the type of perception it was that detected it. That means that as long as you're within perception range, you should only ever get one 'hear' and one 'see' perception event. Unless you leave their range (or go invisible, or duck behind something that blocks line-of-sight), in which case you'll drop off their perception list.

Out of curiosity, have you ever had another 'I hear you' fire after going invisible while still within their perception range? I wonder if invisibility clears you out of both their 'see' and 'hear' lists, or whether you just get removed from their 'see' list alone.

I really wish there was a reliable way of clearing a creature's perception list (just like ClearAllActions clears their action queue). I've tried making them temporarily blind and deaf, but that wasn't always successful. Sending them to sleep seems to do the trick, but results in them falling down (or in the case of my shark experiments, turning onto their backs every round to have their bellies rubbed).