1056 réponses à ce sujet

[Tchos]

I'm glad this project is almost over. I'm getting very weary of the human-centric nature of the whole town. It's not fantastic enough for this fantasy setting. There's not enough magic and mystery. The dialogue I recently finished really drives that home, with all the inclusion of civic politics and financial matters.

There is magic here, of course. There are clairvoyant visions, undead, sacred rituals, magical creatures and monsters of various sorts, investigation of mysteries, and what I hope is a good sense of adventure, but I really need to move on to a new setting that gets deeper into the more fantastical elements that D&D has to offer, with a more magical populace and more fanciful architecture to really fire up that sense of wonder.

Back on the topic of this module, there's one opportunity here for some amount of illogic. There is a journal that the players can find on the corpse of a beaten enemy which leads to further plot. The player might not pick up the journal, or might drop it or store it in a crate for some reason before speaking to the questgiver about it. Is there an elegant solution to this situation which wouldn't amount to forcing the journal on the player and making it undroppable like a cursed item? Elsewise, my inclination is to simply assume that the player has it at the necessary time, and let the plot move on from there.

[PJ156]

Might it be enough that the player had it? The knowledge in it is enough to push forward the plot. Or could it be an item, the player may drop a journal but not a ring of protection +4, set it to stolen and they cannot sell it. Your npc could recognise it and move the plot on. You could take it away or not as the case may be.

That's not an answer to your problem I sure but it might get the story telling juices flowing?

PJ

[Lugaid of the Red Stripes]

You could use a companion as a backup. Say the PC acquires and then unacquires the journal, then you set a variable somewhere. When the PC eventually runs across the questgiver, and says "Oh that journal? I tossed it." The companion can say they pocketed it, and give it back to the PC. If you want to be really clever, you could have the same companion blurt out a barkstring when the PC originally dumps the book, giving the PC a chance to reconsider before the companion snatches the journal.

[kamal_]

questgiver: "You killed the bad guy, but we still don't know what he was up to, maybe you overlooked something in his hideout?" or something along those lines.

I've done just that for quests before, and made the pc go back to the hideout. You don't want to break the main quest (normally anyway), but you can give a bit of punishment for their decision to not take the journal by making them go back.

[Tchos]

PJ: It would be enough that the player had it at one point, yes, although the way it's currently written, the mayor asks to see it and read it for himself. The bigger problem is that the player might not pick it up in the first place. Very unlikely, but possible. It's necessary to pick up one particular thing from the boss' body, to serve as proof of the deed for another party, but the journal is not necessary to close that particular questline -- instead, it advances another one. It's probably not a real concern, as I doubt any player is going to loot the body and pick up only individual items, specifically omitting the conspicuous journal, and NOT simply choose "loot all", but since I have such a labyrinthine network of free choice conditions and refusal options in all other cases here, I thought it might be poor form to leave out this situation.

Lugaid: Another good suggestion, but somewhat hindered in this case because all companions are strictly optional. The player may opt to use an entirely player-created party instead of picking up any of the available companions. But it's true that since most players will probably use at least one joinable companion, that option would dramatically reduce the chances of the situation being illogical.

Kamal: I do actually have a node, journal stage, and conditional check in place for the option of the player refusing the final part of the main quest, so that the player can opt to end the module early, with several statements available where you can choose not to tell the mayor about the journal at all, show the epilogue, and miss out on the rest of the quest. Also in place is the option to first stop the conversation, but then change your mind about that and continue the quest anyway, so it is currently possible to go back and look for it after this conversation, and then come back and pick up where you left off. I could either rewrite it or expand it to another node which doesn't assume that you found the journal and intentionally hid it from the mayor, but never found it in the first place.

All of those suggestions are food for thought. I think I'll go ahead and put in some extra nodes, and see how it goes.

Modifié par Tchos, 26 décembre 2012 - 06:29 .

[kamal_]

Tchos wrote...

Kamal: I do actually have a node, journal stage, and conditional check in place for the option of the player refusing the final part of the main quest, so that the player can opt to end the module early, with several statements available where you can choose not to tell the mayor about the journal at all, show the epilogue, and miss out on the rest of the quest. Also in place is the option to first stop the conversation, but then change your mind about that and continue the quest anyway, so it is currently possible to go back and look for it after this conversation, and then come back and pick up where you left off. I could either rewrite it or expand it to another node which doesn't assume that you found the journal and intentionally hid it from the mayor, but never found it in the first place.

I don't think of those as breaking the main quest, since you have plot written for them they're branching it. I mean allowing the player to do something that's not accounted for that prevents advancement in any direction.

My proof of concept version of Crimmor had an option where you could make a decision and cut off what would be 2/3rds of the full campaign's plot. However I'd planned for it and the story would branch in a completely different direction (a short branch, but it simply didn't go to cutscene-endgame). I've removed that, but I'm considering putting it back in as it means allowing a meaningful choice at that spot in the plot. But in that case it doesn't break the main quest, it branches it.

[Tchos]

Tsongo: I'm inclined to agree. I think it's generally safe to assume that the player wants to play the whole module, and didn't download it and install it simply to choose the "****** off" option and end things before they get started.

There is something to be said for options, though, which I've been using not only to try to suit a range of play styles, but also contribute to replayability. Though it's true that most people will probably only play it once, perhaps years down the line someone will remember playing it before when it first came out, and come back to play it again, a little differently this time.

But truly, if a branch starts to become too twisted, that's when it's time to prune off that branch, like you said.

Kamal: The things I was talking about don't break any quests, no. The concern was that they refer to things that the player possibly may not have done, and I wanted to avoid that. I think I have enough nodes in it now to account for the possibilities, though.

Now, my problem is finding some things not working as they're supposed to again.

[PJ156]

I have come to a similar point this evening, perhaps prompted by the conversation here. I need the player to have an item that an NPC will later use to track them. The plot does not work if they drop it. I think I will make it so it cant be sold and then make it sooo sweet compared with other items available the player is not going to not wear it.

Perhpas they wont, in which case things are going to look a little odd to them but that's the way it is ...

PJ

[I_Raps]

PJ156 wrote...

I have come to a similar point this evening, perhaps prompted by the conversation here. I need the player to have an item that an NPC will later use to track them. The plot does not work if they drop it. I think I will make it so it cant be sold and then make it sooo sweet compared with other items available the player is not going to not wear it.

Perhpas they wont, in which case things are going to look a little odd to them but that's the way it is ...

PJ

You could have an explosion impale it in the PC's chest ....

... Naaah.  No one would ever go for that.

[Tchos]

Or name it "Lord MacGuffin's Golden Plot Device", perhaps. Maybe Oblivion had the right idea after all, making all plot-necessary items undroppable, and weightless to compensate for the imposition.

[Tchos]

Since Dann made a new post in the thread about hidden/unused content in the game, and since in the time since the previous post in that thread I've learned to use Gmax, I decided to see how easy it would be to remove the extraneous candles, inkwell, and table from the ledger model I've been using. Dann did post instructions on how to do that task in SnipMDB, but I never got around to trying it. Despite having those step by step instructions, the command line nature of SnipMDB puts me off.

So I imported the model, selected and deleted the unneeded parts, lowered the model to the ground plane, and exported. Took about 10 minutes from the impulse to try it, to the export. Then I added it to the 2DA.

It took about 20-30 more minutes to figure out why it wasn't appearing in the toolset, and that was because I had put the model in my "play" campaign folder, but not in my "build" campaign folder.

There was still a problem with it, though, and that's that the "smoothing" effect that hides the low resolution of the curves of the open pages was somehow lost between the original version and my exported version. That is, if you set smoothing on, it pretends that any intersection of angles greater than some specified threshold is actually a smooth curve, and it lights the texture that way, even though from the side it's clearly a blocky approximation of a curve.

Here you can see a comparison between the original, with its attached candles and writing set, and the separated version. Note the sudden sharp shadow on the inner section of the left page.



So I assume it somehow lost the smoothing setting, and I've as yet been unable to find where to reapply that setting in Gmax. Ideas?

In other news, I think the mayor's conversation is finally complete with all its branches and conditions. His dialogue file amounts to somewhere around 3200 words. Not sure how that averages with other characters of a similar purpose in other modules.

[Tchos]

Rolo Kipp, master of the arcane workings of Gmax, explained to me how to handle the smoothing. These are the steps:

1. Select the faces. Buttons for "smoothing groups" will appear on the rollout.
2. Put the faces on the top surface of the book into one smoothing group and the faces on the sides in a separate smoothing group.

This fixed the problem. I also increased the max angle for smoothing, though I don't know if that has any effect in NWN2, since when I reimported it, the angle was back to the default, and the separate smoothing groups had reverted to a single one. Something to keep in mind for future model work. I'll have to keep a Gmax format version of the mesh to work from instead of always working from an imported MDB if it loses information like that.

[Rolo Kipp]

<blushing a bit...>

*cough* *Not* master :-P I'm pretty heavily into Max 2010, actually, and have forgotten the limitations of GMax. But the smoothing groups would still work the same.

Re the angle: That just tells GMax which faces to automagically add to a smoothing group (hence your faces merging again). If you are selecting your faces by hand, then that just defeats your manual labor :-P

The purpose of smoothing groups is to tell the GFX card which edges to er, *fudge* <smear?> something like that. Blend! That's the word I was looking for. The boundaries within a smoothing group are blended, making the whole surface look "smooth". Boundaries between smoothing groups are not blended, giving a visual crease. If there are *no* smoothing groups then each face is its own group (faceted look).

<...probably from imbibing too much praise>

Modifié par Rolo Kipp, 31 décembre 2012 - 11:55 .

[Tchos]

That additional information on how the groups are handled helps my understanding as well. I'll do some experimentation with the automatic angle field at some point, and see what I can do with it.

For now, I made one additional tweak to the model -- I moved some of the points around to make the actual physical angles a little smoother. What it could really use is a tiny bit of subdivision, but this will do in this case. One step at a time.

[Tchos]

Something strange is happening with my script to change the appearance of the party members to swimming. Depending on what race I have as the main character, and/or what the race composition of my party is, one of several things can happen. One is that everyone turns into the main character's race, and gains the swimming appearance, or they all turn into the main character's race and do not gain the swimming appearance, or they retain their own races, and gain the swimming appearance, etc.

I have a switch function, and I used numbers for the appearance types instead of their constants, and I ordered them by race instead of in numerical order. I don't know enough about switches to know if it goes through the whole switch to check for a case number, or if it stops if it reaches one higher than what it was looking for. If the latter, then that could be the problem. I'm reordering them in numerical order now to check.

No, that didn't work either. And it's not just the main character's race. In this last test, the main character was a human, and everyone turned into elves.

I use a while loop to cycle through the whole party, checking their appearance type with a switch function, and changing the party member to the appropriate swimming version via a command just after the switch, after which it should go to the next party member and go through the process again.

Okay, explaining just now what's supposed to be going on in this script has helped me read through it and find what was going wrong. It was that the command to check the appearance was outside of the while loop, so it only checked once.

The tests after making that fix shows that it's working properly for a racially-diverse party, although strangely, the script fails completely if the party is larger than 5, which is the max party size that I set in the campaign settings. Despite the limit, you can currently have a party larger than 5 if you create a 5-member party through the party editor, and also recruit additional party members from the NPC companions around town. I was going to just allow the player to do that, and potentially have a 10-member party, but if it breaks the script, then I'll have to actually enforce that limit and run checks on party size when you recruit NPCs.

SoZ handled this by forcing you to dismiss all recruited party members if you go to edit the party, and then recruit back the NPC companions that you still have room for. I'll go with that system.

I copied the cohort scripts from the SoZ campaign folder, and the way they're set up, they use the specific names, resrefs, and tags of the SoZ cohort characters. I hoped the scripts could have been a little more generic, but I can work with them the way they are for this instance by replacing the names and tags with my own companions. Next time, though, I think the scripts could stand an overhaul. I'd create functions that don't need to see which specific companions are in the party -- only how many there are and whether they're cohorts or not.

I'm interested to see in this code that they seemed to have been planning to have the same kind of party dynamics as in the Baldur's Gate games, or maybe Planescape: Torment, in which certain conditions could trigger companions getting angry and leaving the party. It's marked as temporary, and I don't think that functionality was ever used in the game.

[Tchos]

I've been wrestling with more persistent problems.

First, a new potion I've added to the apothecary was only 1g, despite the base cost showing as 730 and an additional cost set to 400. I found the problem, though. It was set to plot. Removing the plot flag corrected the price. Not sure why having a plot flag in a store item would cause that item to be sold for only 1g, but something useful to know in case I want to have a plot-necessary item sold in a store, and want it to cost more money. I'd have to set it to add the plot flag on acquire, probably, and have the store sell it without the plot flag.

Second, the mayor's quest indicator was doubled. Couldn't figure out why, since the others weren't. It must have had an extra one added by something, but I couldn't find what it was. I made an extra safety removal at the outset, and that fixed the problem.

The mayor sits in a chair, and I wanted him to make some gestures while talking. Doing it through the animation or node section of the dialogue tree caused him to stand up and sit down repeatedly while doing these gestures. I created some new ga_ scripts to handle gestures with PlayCustomAnimation() which kept him in his seat. However, after leaving the area and returning, I found him standing up again.

I added an On Enter script to the area to re-fire the script that seated him in the first place. However, that caused him to sit in his chair backward. I changed the script to just refire the sitting idle animation instead, and that put him back in his seat.

Since I had to restructure the system of companion recruiting and removing to enforce the limit, I brought in some adapted SoZ scripts. However, I'm having a lot of trouble getting them to work properly, where Kaldor Silverwand's adaptation of Dick Lorraine's companion recruiting and removing worked as it should have, though disregarding the limit. I'll continue to work on that.

Okay, after extensive investigation, deliberation, and testing, I went back to the old way for part of it, while keeping the SoZ scripts for other parts. As far as I can tell, it now works as intended. You can have a maximum of 5 party members, regardless of whether they're player-created (imported PCs from your local vault) or recruited NPCs (cohorts).

To recruit an NPC in the first place, you have to talk to them. After they agree to join your party, they will appear in the party roster, whether or not you have room for them. However, if you already have 5 party members, they will not join your party until you remove one. This is true whether you attempt to add the NPC through conversation or through the party roster editor.

Editing the player-created party members requires going to a tavern or inn, and using the guest registry book. You can add and remove both kind of companions with the guest book. Player-created characters which were imported from your local vault, which you remove from the party in this way will appear to disappear from the game world until you re-add them from your local vault with the same process, but in my tests, the game does remember the state of those characters, even after saving and reloading, so your inventory and everything else should be safe when you re-add them. There's only one thing to remember, and that's if you have multiple copies of the same character in your vault (e.g. Brigid Chandler, Brigid Chandler (1), Brigid Chandler (2),etc.) as you might have if you export the same character at different levels, you have to remember to re-add the same copy of the character that you imported the first time, or else it's counted as a different character.

Once an NPC has agreed to join you the first time, you can add that NPC anytime you have enough room, either by talking to them and asking them to come along, or through the tavern guest book, or though the party roster menu option in the player menu.



You can remove them from the party in the same ways (talking, tavern guest book, or menu selection). If you choose either of the first two options, those cohorts will remain standing where you leave them in the taverns until you re-add them, but if you use the party roster menu option in the player menu, then the cohort will disappear from the game world until you re-add her/him. And of course, the inventory and level is saved, as normal.

So far so good, and several items crossed off the list.

[Dann-J]

[quote]Tchos wrote...

I've been wrestling with more persistent problems.

First, a new potion I've added to the apothecary was only 1g, despite the base cost showing as 730 and an additional cost set to 400. I found the problem, though. It was set to plot. Removing the plot flag corrected the price. Not sure why having a plot flag in a store item would cause that item to be sold for only 1g, but something useful to know in case I want to have a plot-necessary item sold in a store, and want it to cost more money. I'd have to set it to add the plot flag on acquire, probably, and have the store sell it without the plot flag.
[/quote]

Plot items have a buy/sell price of zero to prevent the player from selling them, but I suspect there is an error trap in the store scripts that makes sure the minimum price is 1gp for everything. Otherwise merchants would be giving things away, or even worse, selling at a negative price if the player's appraise score was high enough.

[quote]Tchos wrote...

The mayor sits in a chair, and I wanted him to make some gestures while talking. Doing it through the animation or node section of the dialogue tree caused him to stand up and sit down repeatedly while doing these gestures. I created some new ga_ scripts to handle gestures with PlayCustomAnimation() which kept him in his seat. However, after leaving the area and returning, I found him standing up again.

I added an On Enter script to the area to re-fire the script that seated him in the first place. However, that caused him to sit in his chair backward. I changed the script to just refire the sitting idle animation instead, and that put him back in his seat.
[/quote]

Setting looping animations in an OnSpawn or OnEnter script doesn't always work, unless you delay the commands enough to ensure the NPC is fully in the area when the animations are set.

Heartbeat scripts are usually a better option for setting permanent looping animations. If the first firing doesn't work, then there are plenty of backup attempts every six seconds. You have to make sure the NPC isn't engaged in some sort of activity though (not in conversation, not in combat, nothing in the action queue, etc), or their new idle animation will impose itself when it's not wanted.

There are still things that will shock them out of their looping animation though, such as bumping into them or initiating conversation. It always pays to have sitting or prone NPCs unbumpable, and to not orient on dialogue. Sitting isn't well supported in NWN2, as I'm sure you've discovered while trying to script it to happen. It's a constant fight against the game's core behaviour just to keep them in their seats.
[/quote]

[Tchos]

Yes, I make sure that my sitting scripts set the no-orient flag for dialogue, or else I stick it in the On Conversation field.  Most of the time I also make them unbumpable, but in this case I didn't, because I actually blocked off the area from the walkmesh so that the player doesn't run around to the other side of the mayor's desk to talk to him.

This, however, has the side effect that you can talk to him from across the room.  I tried a different method in other desks and counters, creating a thin walkable space just in the middle, and in most cases the PC automatically stops just short of what's supposed to be a solid object as long as you clicked to talk to the NPC, but it also is possible to continue walking through it.  Since that will not happen most of the time, I think it's actually less of a break from immersion to have those occasions where it does happen, rather than running around to the other side.  Between that and blocking off the area entirely, I can't say which I prefer.

"or their new idle animation will impose itself when it's not wanted."

That is why I chose not to use a heartbeat for this case, but I suppose if I include those checks you mention, it would prevent the interruptions I was anticipating.

[Tchos]

I had a long list of things that needed to be done to the docks area -- that large area that seems to grow ever more difficult to open. I took a rest from working on the last of the exteriors, restarted the computer and loaded the bare minimum system resources, and tried opening the area with all effects and visible items turned off. A fresh reboot with nothing else loaded and everything turned off has been the only thing that's worked in the past, but this time I was greeted by a very disheartening crash.

However, I thought this time to take the precaution of reducing the far plane distance in the options, as well as reducing the display resolution, and upon trying again, this successfully opened the area. Finally!

So I went about taking care of the items in my long list (mostly adding spawn points, fixing some misaligned items, adding missing walkmesh cutters, and improving navigability), and despite several more crashes, I implemented nearly all of the things that I needed in that area, and left it open to go out for a few hours. I returned to find it had crashed again during my absence, for unknown reasons, but of course I had saved before leaving, so it's all right.

What remains to be done there, as far as I can tell, are just some descriptions on placeables (in this module, all doors are named to indicate their destination, and shop signs include descriptions of the shop that you can read before entering them, to know what you're getting into), and placement of sign posts. Everything else can be handled through scripts without opening the area again, since I have the waypoints and item tags documented externally. There are cosmetic things that I would like to do (proper signs with graphics), but I'll do without here.

[kamal_]

Tchos wrote...

I had a long list of things that needed to be done to the docks area -- that large area that seems to grow ever more difficult to open. I took a rest from working on the last of the exteriors, restarted the computer and loaded the bare minimum system resources, and tried opening the area with all effects and visible items turned off. A fresh reboot with nothing else loaded and everything turned off has been the only thing that's worked in the past, but this time I was greeted by a very disheartening crash.

When I open my city exteriors, I set the toolset to not show anything, and have no problems opening them. Then I turn on anything I need once the area is open. If I have the normal stuff turned on when I open, placeables, environmentals, trees, etc, it can choke when opening.

[Tchos]

That's what I'm talking about when I say I tried opening it with all effects and visible items turned off. It's also set not to show sky, fog, water, etc. It wasn't enough in this case.

[Tchos]

There's a signpost up ahead. Your next stop...?



Right, so as I mentioned before, I needed signposts for the town, to help the player get around town, and I didn't find anything like this in the available resources. Asking directions or consulting the map for map note pins is all well and good, but how about actual street signs? This is what you might call my first foray into real model manipulation for this game. I've done this sort of thing before with the simple tools available for Oblivion (Nifskope), but here, I had to use Gmax. The modeling itself didn't take too long, but learning to navigate Gmax's methods of creating a UV map for this mesh (with more shapes than I've mapped before) took an entire day. The other day was spent actually texturing it.

I put some intentionally illegible writing on the signs so that they can be used generically. I didn't want yet more blank signs like what I've settled on for the shop signs.

There is a very nice pack of merchant signs that I plan to check out when I have the time, but it won't be in this module.

Anyway, as is no doubt evident from the screenshot, I have the sign arrows separate from the post itself, so that you can name each arrow appropriately, and also to add or subtract arrows as needed. I made a prefab group out of it, for easy placement around town.

I'd say it's a slight improvement over the directional signs they used in the OC.

[Lugaid of the Red Stripes]

I just think that separate-arrow idea is awesome. Especially with the default action set to examine, it's a great way to get information to the players and help them navigate into the world. Well done!