1056 réponses à ce sujet

[kamal_]

Iveforgotmypassword wrote...

Good poster ! I don't know about the price being too low, if one bottle of spirits costs 1gp and if here in England it costs £10 then that makes a £25000 reward which is quite repectable .. Then again elves are pretty rare in these parts so you could be right !

Depends, if it's wanted dead a dwarf will take care of some elves for free. If it's wanted alive that barely buys enough grog to make it worth putting up with the elf while you drag him back to authorities.

[Dann-J]

You should be able to set your doors and chests to plot, then give them an OnSpellCastAt script that checks for the knock spell and unlocks them accordingly.

The downside to giving your 'indestructable' items huge amounts of hit points is that instant-death spells can still destroy them if they fail their saving throws (which they always seem to do).

[Tchos]

Tsongo: Well, I was thinking more about the reward versus the amount of risk involved, since Sand's a pretty powerful wizard by the end of the game.  But it's true that this amount of money would be very well paying for any normal job.  Especially since in P&P, food and drinks are worth considerably less than 1g, but since NWN doesn't deal in silver or copper, there's a lot of inflation.

Kamal: Especially if it's Sand, since he'd be snarky and insulting to the dwarf the entire way back.

Dann: That sounds like the best solution, and actually less of a bother to implement than adjusting the hit points, since I can just create a saved script set for doors and chests that I can load on those instances.

---

P&P day prevented work, as usual.

Today I needed to tackle timing problems with my event script. Some things were firing immediately and ignoring my delay command (such as effects). Other things were not happening at all in this script, where they worked in the trigger (such as spawning and fade to black). Upon reflection, I believe this is probably because I was executing the script from the potion, and when the potion was destroyed upon consumption, it may have broken the execution of the script. Perhaps not, but I decided it would be better to use the switch heartbeat method I had used before on Heartwarder Adeline.

I edited my script externally, as I often do, because I find the script window to have some unpleasant behaviour, and the external editor's ease of use outweighs the disadvantage of having to switch back to the toolset to look up commands in the Helper. I also write much of my dialogue this way, rather than in the toolset, and that's mainly because the dialogue editor is so bloody small, and always reverts back to its original size instead of the larger window I resize it to -- not that it matters much since that box seems to have the only font that can't be changed in the preferences. And of course there's no word-wrap on the node display. As I'm sure I mentioned before, I use an old version of EditPlus, with colour-coded syntax. I've heard others recommend Notepad++, which I'm sure is very similar to what I'm using, and is free, but I've tried using it before, and I had a problem with it always reverting to default options when I opened it by double-clicking on a file, though it had my preferences intact if I opened the program first, and then the file.

This is much more involved scripted event than the previous one, complete with music change, atmosphere/lighting change, time passing, effects, conversation, multiple spawns and actions, etc.

I placed an ipoint into the area, for running the heartbeat. I've never used an ipoint before (don't even know what the name means), and I guess the difference between it and a waypoint is that an ipoint is just an invisible placeable that can have scripts applied to it, while a waypoint has no script slots. I'm not sure what advantage there is, if any, to putting my scripts on an ipoint instead of on a placeable that's already in the area as decoration (like for instance, a nearby wall, which will never be destroyed), except perhaps that it stands out visually as an obvious "script container".

I guess a lot of what I'm doing here is the same sort of thing that would be done in a standard cutscene, and since I've never made any cutscenes before, it's yet another learning challenge. The main difference, I think, is that I'm not running what would otherwise be a conversation switch from a conversation, except where convenient.

It seems that I can't continue having an NPC speak lines from a conversation if I kill that NPC through a script. The script had said that it only makes the NPC appear dead, but the effect was that he stopped speaking, and the script stopped advancing. Next test run will have the important speaking NPCs have a knockdown effect applied instead, and the others will be killed.

The annoying thing with these scenes is having to run through them over and over to adjust timing, see what's not firing, or what is firing and shouldn't be (repeated spawns instead of an intended explosion?), etc. I've spared you reports of the dozens of playthroughs with this one, but as it currently stands, there is no knockdown happening, and no explosion.

Edit: Never mind the last sentence.  It was a simple error in assigning a case.

Modifié par Tchos, 19 août 2012 - 11:49 .

[Dann-J]

I assume 'ipoint' stands for 'information point' (but that's just a guess).

Whatever the origin of their name - they rock big time. They have all the advantages of using a creature or a non-static placeable to run scripts or store variables on, but without the risk of them getting killed/destroyed. They also don't ignore the commands you give them because some other behaviour script overrode things (OnPerceive, OnAttack, OnDamaged, etc). They sit invisibly in the background, do as they're told, and don't try to make decisions for themselves. The toolset version of a 1950s housewife, in other words. I use them extensively (ipoints that is, not 1950s housewives).

Their only downside is that the default ipoint blueprint has an extra space at the end of it's tag name, that has been the cause of much scripting woe.

[Tchos]

Well, it's good that you mentioned that, though I didn't encounter the tag name space, since I had immediately changed its tag to a unique name so that I could issue it commands from the potion and the conversation scripts.  I'll probably deal with it by making my own campaign-level ipoint blueprint with a fixed tag, and always use that one.

Though many of the advantages you mention can also be done with normal placeables if you just remove all of their scripts and make them undestroyable, they definitely win points for convenience and fitness to purpose.

[Lugaid of the Red Stripes]

Like a well-trained 1950's housewife, i-points also make good conversation partners. Especially if one of your NPC's is gonna die halfway through, you could just run the conversation on the i-point, and shift to the NPC speaker by using his tag. You can also do the opposite, refer to an i-point in conversation by tag. They don't exactly move their lips when they talk, but at least you can point the camera at a specific spot without using a static camera. They're also useful targets for various spells and VFX that have to be aimed at an object rather than a location.

[Tchos]

There will be no cameras or moving lips in my work, but if the knockdown effect doesn't work in lieu of the NPC deaths, I'll try running the conversation on the ipoint since I happen to have one now.

[PJ156]

It would be quite rare for me to not use an Ipoint now. They are exceptionally flexible for this purpose. As the conversation needs to be applied to the Ipoint I am not sure that a campaign wide one will work. You will need one for each conversation.

I had lots of problems with death animations in conversations, especially if the player leaves the body then come back to the area later. My dead person would invariably stand up. I would be interested to hear how you fix this one as I left this as a bug in my last outing but will fis this proper in the campaign version of the module.

PJ

[Tchos]

This dead person's body is destroyed at the end of the scene, so there won't be any problem with standing back up later. If I can get it all working properly, that is.

[Tchos]

The reason for the repeated spawn instead of an expected explosion was because I had told the script to advance to stage 400 a second time instead of advancing to stage 600 as I had intended.

One thing I wanted to have happen is that some NPCs would bash something repeatedly. I got them to do it once, but they gave up after the first hit. I got around this by delaying a command to do it a second time, but surely there's some command or parameter somewhere that makes it ongoing. I've seen henchmen start bashing doors that I failed to unlock in the past, and they kept it up until I stopped them.

I couldn't get the knockdown effect to apply to the NPCs at all, so I tried moving the conversation to the ipoint, and using the death effect. The death effect works, but moving it to the ipoint didn't solve the problem of the NPC not being able to say a few parting words as he lay dying on the ground. The conversation still broke once he was dead.

Also, moving it to the ipoint created the new problem that one of the NPCs would always turn to look at the ipoint instead of the other NPC that was speaking, despite setting both speaker and listener in the nodes. So I moved the ipoint to a spot in between the two speakers.

So I added some SpeakStrings to the script instead, and assigned them to the NPC's spawn waypoint, thinking that would be better than the goblin's body, since I was having so much trouble with it. Bad idea, I guess, because the waypoint couldn't speak.

Finally, I assigned the SpeakStrings to a placeable that was in the same location, after first converting it to a placeable from an environmental, and remembering to give it some hit points. I also marked it as able to speak to non-player-owned NPCs, just in case. That worked. Finally!

It's pretty much all running properly now, with the exception of the fact that they're dropping loot, and they shouldn't be in this case. I'll see if I can fix that by removing their death scripts, or their spawn scripts, depending on where the loot is being generated.

I checked. It was the spawn script, and just adding a variable to the blueprint is enough to stop them from dropping loot.

There is still one small thing, and that's the placeable speaking the string shows the placeable's...not name, but appearance. I tried changing the name to something more appropriate, and also tried enclosing the name (Localised name) in curly braces, but it ignores that completely, and goes with the name as it appears in the item's Appearance field. When I applied it to a new ipoint instead, the floating text then had the word "[Ipoint:]" prefixed to it (again, the name in the localised name field was enclosed {like this}), so I changed it back to the other one. It's not an entirely inappropriate name, but it's not very optimal. Nothing else I've tried works, though, and since it's otherwise all functional, I'm going to call this scene "finished".

Now I just need to finish up the quest dialogue for it, and that's out of the way.

I think I'll have to drop the last of the side quests I was planning and had partially written. It would have been at least as involved as this one, and required 3-4 more areas. Another one for a future module. I think it would fit just as well into the next one I have in mind anyway.

[Tchos]

I finished up the quest, tidying up the big scene, doing journal updates, filling in the placeholder text, fleshing out the rest of the conversation, and creating and giving the quest rewards. I find it satisfactory.

I still need to implement the local area's drain on the player's attributes (only if the player is an elf or half-elf). Possibly the Duskwood area in the OC can be an example of how to do that.

I also took a little break and allowed myself some play time, playing Ernie Noa's module Tomoachan, chosen mainly for its brief length. By happenstance, he has a ship-to-ship battle in his module, too.

[Tchos]

I've hit a real-world stumbling block, and I currently can't access my module work or my log of the day's accomplishments, as my main computer is currently out of commission.  I'm writing this on my little netbook, which I regret to say is not capable of running NWN2 or the toolset.

The good news is that my work is most certainly safe, because the malfunction is, as far as I can tell, solely related to the power supply (the fan box in the back of the computer that you plug the electrical cable into).  That, and I keep online backups, though I think the last backup was a couple of days ago.

A few hours ago I was on the computer, and started smelling that burning plastic sort of smell that heralds the imminent escape of the magic blue smoke that animates electronic components, and upon whose escape the computer no longer works, because it's impossible to get the magic blue smoke back inside.

Anyway, I determined that it was coming from the power supply, and not any of the other electronics in here, by following my nose.  After shutting down as quickly as poosible, I felt unusual heat radiating from the power supply casing, and on a quick test I found that the fan no longer runs, and seems to be stuck.

The power supply might still be under warranty, or it would have been if the company that made it weren't out of business now, as they are.  So, another unexpected and difficult (but necessary) expense for me.  I should be able to get it running again by tomorrow.

[MokahTGS]

Those malfunctions also allow the escape of the magical imps that turn the gears inside the computer...which oddly enough you can only see if you inhale enough of the magic blue smoke.

[kamal_]

MokahTGS wrote...

Those malfunctions also allow the escape of the magical imps

I believe I saw that quest in the OC.

[Tchos]

Ah yes, imps. It must have been their wicked giggling that I was hearing on some other occasions when things broke down. Sort of a creaking, grinding noise, right?

[Tchos]

For those who may not know, such as those who never open up their computer cases to put things in or take things out, the computer's power supply is essentially the computer's heart, much as the CPU is its brain. It even looks like a heart, albeit a blocky, robotic one. If you're ever in battle with robots, I think a good shock tactic would be to pull out the power supply of a fallen foe, and brandish it in view of the rest of them, trailing its wires like blood vessels.

So, what I was doing was heart transplant surgery, with my desk as the operating table, the poor unconscious computer's case wide open and exposed under my desk lamp, with the failed heart removed but still connected, and the new heart waiting next to it. To be sure of no mistakes, I disconnected one wire's connector at a time, and replaced it with the new heart's wire of the same kind of connector. I'm glad they make them all different shapes. Cuts down on a lot of unnecessary errors.

In the middle of this procedure, though, I had to take the whole thing outside, because it was choked with dust inside the case, and in need of a thorough blowing out. I'm not sure how bad dust is for electronics, since most of the warnings about it that I see come from companies that provide dust removal services, but it seems reasonable that you don't want debris of any sort settling on bare circuits.

The procedure was a success, with no complications, and I'm typing on my much cleaner computer now, with a brand new power supply that I hope will last longer than the previous one. My graphics card is probably the biggest burden on it, since it requires a 400W minimum.

So, on to the modding.

I discovered something surprising when I applied the wrong script to my ipoint -- an older version of the script that didn't have any conditions, so it fired constantly when I put it on the ipoint's heartbeat. It fires when I haven't even gone to that area for the first time yet! Can this really be true? The game loads every single area in the module when you start up, and it runs each area's scripts? I'll need to check my heartbeats and make sure I have a condition in there to abort if the PC isn't nearby.

Playing other modules like I did yesterday gives me a better idea of the sort of things that have already been done in this game. I'm sort of blind in my selections, though, not really knowing which things to play, and selecting them by what sounds interesting or how long it would take to play them. This isn't the place for a review, though, and I'm not comparing my module with other existing ones. My design philosophy is based around the things I've seen in the official campaigns and in other similar games, and as mentioned before, what I want to see in games (and as little as possible of what I don't want to see in RPGs in general).

Nevertheless, seeing what others have done is invaluable in the learning process, as well as picking over the official campaigns to see how to accomplish things, as I did for my area-wide "curse" effect. It turns out it's pretty straightforward, but I wouldn't have known that without looking.

As usual, I had a list of notes on things to fix from my playtests, and reminders of things that I skipped over the first time, to make sure I don't forget to add them in.

As it probably made evident in my earlier post showing the ogre varieties, what I'm doing with my encounters is to pit the player against "parties" of monsters/enemies of a similar sort as the player's own party, to create a fair challenge that I hope will be interesting and fun.

I learned something very useful here. That on client enter script I had been using to spawn NPCs and creatures, which I took from the SoZ on client enter script for taverns, had defined a function to spawn specified creatures from their resrefs. I had made the script multipurpose by having it take the resrefs from local strings on the area's properties, but I had recently been making custom versions for certain large areas that are prone to crash when opening, or for areas that have special properties. In doing so, I noticed what I hadn't noticed before (and probably wouldn't have been able to notice before, since I couldn't understand or recognise loops), that the spawning function uses a while loop. So that means I don't have to specify a particular enemy more than once -- I can specify a certain type of enemy, and place as many copies of that enemy's waypoint into an area as I want, and they'll all spawn. This makes it easier and more flexible than the encounter system for placing enemies. I had previously only used the function to spawn one unique creature at a time.

I think I might even be able to make each waypoint spawn more than one enemy, or a random number or selection of a specified pool of enemies. Randomness I don't need for this, but spawning more than one, perhaps 3 at a time if I need that many of a certain type, would be tidier to look at than 1 at a time, cutting down the number of waypoints to 1/3. I'll try that out on the next level of the lighthouse.

[Lugaid of the Red Stripes]

About heartbeat scripts: It used to be that all the heartbeats ran all the time, but patch 1.21 or thereabouts throttled that. HB scripts in areas without the player will run at first, then less often (like every 20sec) before stopping altogether. The same gradual reduction will happen whenever a player leaves an area.

Your talk about opfor parties made me think about how hard it would be to throw together groups of enemies at runtime distinctly calibrated to exploit a PC party's weakness.

[Tchos]

Good to know about the heartbeats. I guess that would be a failsafe against mistakes like what I made above.

As for parties, I didn't mean I'd make them dynamically tuned to the player! I just mean I'm including some typical well-balanced parties of a similar level as I recommend the player's party to be. Otherwise it would sound like level-scaling, and I don't advocate the use of level-scaling, because it eliminates the feeling of progress in the game if enemies always pose the same amount of challenge no matter how much you level up.

[GFallen01]

Tchos wrote...

In the middle of this procedure, though, I had to take the whole thing outside, because it was choked with dust inside the case, and in need of a thorough blowing out. I'm not sure how bad dust is for electronics, since most of the warnings about it that I see come from companies that provide dust removal services, but it seems reasonable that you don't want debris of any sort settling on bare circuits.

The procedure was a success, with no complications, and I'm typing on my much cleaner computer now, with a brand new power supply that I hope will last longer than the previous one. My graphics card is probably the biggest burden on it, since it requires a 400W minimum.

Hardware... a battle it is. My rig is 8 years now, and I've had to replace most of the components as they just fail one after the other. A few months ago I also bought a new PSU, as two old ones died in a row.

As to dust, an important issue with that is that it's an insulator - a blanket as you will. So it may cause overheating, and thus instabilities.

As to your graphics card requiring "400W", that's more a claim of GPU manufacturers to keep support calls low. Probably because many PSUs, mostly "generic" varities, don't deliver what they say on the package.

[Tchos]

So the dust itself may have caused the fan's breakdown, increasing friction or something like that? Which then led to the power supply overheating and starting to melt. Either way, I'll try to dust more often.

[Dorateen]

Tchos wrote...

As it probably made evident in my earlier post showing the ogre varieties, what I'm doing with my encounters is to pit the player against "parties" of monsters/enemies of a similar sort as the player's own party, to create a fair challenge that I hope will be interesting and fun.

Huzzah for battles with enemy parties! Looking forward to it.

[Tchos]

I created some more treasure items for quest rewards, and added them to the item that will deliver them. I browsed through the sounds.zip file in the data folder again to find a suitable sound effect for the delivery, and came across some sounds that I don't think I've ever heard in the actual game. For instance, there's a file called gui_quest_done.wav, which plays a little tune, clearly meant for the final journal update at the end of a quest, but in the actual game all we get is the same "ding / scribble" sound as any other journal update. I wish they had left that in, and I can't see why they didn't! But I can remedy that for my module.

There's also an eating sound effect, called gui_eating1.wav, which sounds like someone eating an apple or similar crisp item. I don't recall any actual edible food in the game, but I could be forgetting something. There's also gallop.wav, despite no ridable horses before mods. And hilariously, a file called wilhelm_scream.wav, which contains...the Wilhelm scream.

I also went through the longest of the side quests from beginning to end, to make sure everything worked. Before, most of my tests had skipped to particular stages. I found one conversation error, but it was at the very end, when the player can offer some parting words to sum up the party's feelings on things, after the rewards have been distributed. But there was another list full of things to fix that I found along the way, not directly related to the quest.

[Tchos]

There didn't seem to be an easy way to set an ipoint to use low-level AI when the PC's not in the area, like an NPC can. I should be able to do the check manually, but in the meantime I've settled on the solution of destroying the ipoint after the quest that involves it is over. I'm not sure if setting it initially to "script hidden" would prevent its heartbeat execution until I unhide it when the player takes the quest.

I tried out the spawn waypoints for the purpose I mentioned yesterday, and use them to create three new encounters with well-balanced (in my opinion) parties of enemies, which was a lot more fun in my playtest than the boss+minions type encounters I had put in so far, and more importantly, it actually presented a good challenge to my party! After each fight, my party was pretty beaten up, as they should be, though I think I could have gone through all three without resting if I would have taken the time to have my healer patch everyone up. So, it seems pretty well-balanced to me. There should always be a chance of dying in encounters like this if you play with my recommended party level, but if played intelligently, you should be able to get through without any deaths (unless you get some unlucky dice rolls).

Speaking of healing, though, I couldn't see any evidence that the enemy healers I had placed in the encounters were actually doing the jobs I wanted them to do (healing their allies), or if they were attacking my party instead. Is there a way to force an NPC to perform only a support role, and stay out of the way until someone needs healing?

I'm going by the book on what kind of equipment the party should have at this level. Each party member is expected to have a total worth of 49000 gp at level 10 which they would have acquired in past adventuring, which means each character should have good class-relevant equipment worth about that much gold. I've done my best to make good equipment for every class available for purchase in town, so if you're starting off with a new level 10 character with something like Vordan's Hero Creator, I'd recommend setting up with the default expected gold and making your purchases in my module instead of in the character creator module.

I just have to say, some days I really, really love this game and toolset. This game occupies a very privileged niche alongside such luminaries as the Infinity Engine games, Arcanum, and the Temple of Elemental Evil. I've tried many others, and I really don't think there's anything better.

I discovered a mistake that I had made near the beginning, before I understood that GetFirstPC() is a "last resort" method of referencing the PC, and not even the best method. I read through a thread pointing out that almost every event that can fire a script has its own optimal means of referencing the PC, but before I knew any of that I had used GetFirstPC() for the hearthstone script, and it was for that reason that no matter who used it, the first PC in the party would perform the animations and effects of it. Now that I know a little more, I changed it to GetItemActivator(), and that fixed the problem.

I fixed up the rest of the problems I had put on my list, and moved on to start the 2nd level of the lighthouse. In the original module, there were 4 levels total, including the loft. I'm cutting it down to 3, because there would have been nothing really interesting in terms of gameplay on the 2nd level, and the few interesting atmospheric bits can be merged with what was originally the 3rd level, along with my embellishments. I don't know about others here, but I hate unnecessarily large areas that have nothing to do and nothing interesting to see in them.

I also had to attach a conversation to the door on this floor to allow the player to select going upstairs or downstairs.

[Dann-J]

Going back to the ledger model question - a bit of experimentation has proved that you *can* use SnipMDB to separate out parts of a multi-part model. I can post details if required.

Unfortunately the ledger model is only in two parts - the bench, and everything on the bench. I was able to separate the two, but it means that the candles and the ink well are attached to the ledger. It would be possible to make them invisible though, by altering the alpha channel on the diffuse texture to clip them out, leaving only the ledger itself.

[Tchos]

Dann, yes, please do post details on the SnipMDB procedure, either here or elsewhere. I'm sure that information could be of use to others as well as myself.

Aside from the normal P&P session, I also took another little break to play some other things, including the recently released Fanglewood.

Now, where was I?

To make sure it's a reasonable challenge, I just did another playtest of the forest area after optimising the spell selection of the spellcasting enemies, and setting them to buff themselves when the player's party approaches, using the bitwise variables in NW_GENERIC_MASTER to set the spawn flags, and likewise set the enemy rogues to stealth and search mode.

Using a party of 5 characters, all level 10 except for the barbarian who was level 9, I was able to beat every encounter in the area on the hardest game difficulty, without resting, and without specifically bringing equipment and items tuned to these particular encounters. It was tough, for certain, and I did have a character fall down bleeding 2 or 3 times (SoZ death and bleeding system), but I was always able to bring them back into action with healing, and without needing to raise the dead. The party consisted of a fighter, a barbarian, a bow-wielding ranger, a caster druid, and a buffing/healing cleric. Between encounters I used up many of the healing potions I had in my inventory, and during the battles my cleric used up all her healing kits (I think I had about 10 low-level ones) and spells.

Since the player does have the option of resting, as well as going back to town for supplies if needed (healing potions and healing kits are available in unlimited supply at the temple), and can also set the game difficulty lower if needed, I'd say it's at a good level of challenge. Tough enough for those who want it to be tough, and still doable for those who don't.

Okay, now back to level 2 of the lighthouse.