Tchos Posted August 12, 2012 Author Share Posted August 12, 2012 The past couple of days have been minimally productive due to the usual weekly P&P session and my birthday celebrations. What I did was to write most of the other two quests -- "Song of Aino (You Were Loved)" and "My Love is Vengeance" -- which touch on some strong emotional themes. Well, I found them moving, at least. Your mileage may vary. The only other news at the moment is that Eguintir Eligard and I have made an informal collaborative agreement in regard to creating new placeables that can be of use to both of our projects, wherein he provides the meshes, and I texture them. I just received several such meshes today, including a versatile plane of the kind I had wanted before, in two orientations, and a singular potion bottle. Others are planned. So I guess there'll be a somewhat more substantial placeable pack than I was expecting to be released. I'll show these once I've textured them. Link to comment Share on other sites More sharing options...
Tchos Posted August 14, 2012 Author Share Posted August 14, 2012 (edited) For a conversation, I wanted to include a special option for if there's a ranger in the party with fey as a favoured enemy, along with other more general special options. I looked through the available scripts, and didn't find any, either searching for "favoured" or "favored", though I could have sworn I saw a check for something like that once. I also searched on the Vault script sections for both NWN1 and 2. Lastly, I went to Lilac Soul's Script Generator, and chose an option that I'd almost never had occasion to use before, that being the starting conditional. It informed me that what I needed to do was just check for the constant of a feat, since all of the favoured enemy choices are individually numbered feats. So I ended up just making a new gc_ script that's essentially the same as the "check feat" script, except that it's named for what I want to check (easier to find) and it has a list of all the possible favoured enemies right there in the script comments, where the usual feat-checking script refers you to a larger include file. Next task was a condition to see if the player speaker is neutral on either of the axes. That seems to be more complicated than it should be. For now, I'm going with a check for "not good" and "not evil", or "not lawful" and "not chaotic", and see if those work. The disadvantage is that true neutral characters will probably see the dialogue option twice if I use the standard check scripts, since they don't handle compound ANDs and ORs. This is also one of the conversations where I'm including the ability for player-created party members to discuss a course of action amongst themselves. It's in a fairly limited fashion, but since different party members will have different options available to them based on their class, alignment, feats, etc., a typical well-rounded party would likely have some conflicting motivations. There is an opportunity to be evil here, if the player wishes. One problem, due to the aforementioned options and conditions, is that certain combinations, such as a lawful evil character, may propose doing something evil, and then be able to gainsay him/herself by pointing out that such an action would not be right. Next I needed to decide between spawning and destroying a creature, or using the "script hidden" property I'd never used before. I decided to try spawning the creature as script hidden, and changing it with a script. Then I found that I was wrong about being able to make anything usable. Apparently trees don't work that way. So I opted for a speak trigger to start things running, where I had intended the player click on the tree to do so. Perhaps it's just as well, though, because I think the description of the tree is an important prelude to the quest, and the player could easily have missed the opportunity to examine the tree, whereas now I'm having the description in the popup DM text window instead. Still, it's an "ambush" style forced conversation, which I don't prefer. It turns out it was more straightforward to spawn the creature when needed, rather than spawning script hidden. I did cache the creatures who'll be spawned, though, to avoid a stutter on spawn. As a kill quest, it was pretty straightforward to set up, and simple in execution. As is usual in cases like this, it's the writing and story that surround the quest that I intend as the point of interest in playing it, and not the mechanics involved. That's for other quests. It's possible, though only barely possible, to miss this quest altogether. It's perhaps easier to miss quests back in town, though, because they're mostly inside the dozen-odd individual shops, and there are only two buildings in town that you actually have to enter in order to finish the main quest. This module rewards exploring. I'm again bothered by how quickly the fights are over, and how little damage is taken by the party. I'm sort of sad that I never really got to make use of the quest-maker plugins, because by the time I had learned enough to understand how to use them effectively, I had learned enough that I didn't need them in the first place. I would have liked a little more of a honeymoon period. I suppose that's why there aren't very many beginner's utilities out there for this game. I know there's some built-in functionality in the default scripts to have a creature bark a one-liner when it sees the player and starts attacking, but I can't seem to find documentation on how to use it. This is one of the new placeables I was talking about in the previous post, by the way:http://4.bp.blogspot.com/-4VOLOFhfyqM/UCl6CPzQgDI/AAAAAAAADm8/IPDa4iIm5Qs/s320/bcocc%2Bpage.jpg Edited August 14, 2012 by Tchos Link to comment Share on other sites More sharing options...
Tchos Posted August 16, 2012 Author Share Posted August 16, 2012 With the yearly events now behind me, it is time for more...experiments. I had a little problem with a death script, which I based on nw_c2_bossdie, an older script from 2001, but seems to work fine, for the most part. I use scripts like this for generating random treasure on tough fights, and updating journals and such. The problem, which hadn't happened previously, was that it upon killing it, the treasure was generated on the PC rather than on the creature. The script passed the PC through the script "to determine treasure", it said, but I crawled through the referenced functions, and determined that there was really no reason to mention the PC at all, because the treasure generating functions are only supposed to consider the PC if the treasure is being generated on an object. If it's on a creature, then the creature's type and level is the only thing that should determine the treasure. So I removed the reference to the PC in the death script, and left both of the parameters at their defaults of OBJECT_SELF. That fixed the problem. "Script hidden" was not the best way to have the dryad emerge from and return to her tree. I already mentioned I used a normal spawn to bring her in, but at the end of the quest I tried using script hidden to make her despawn, thinking she would fade away smoothly. Instead, she just abruptly vanishes. I looked around, and didn't find any general purpose "despawn" scripts, but eventually found the ga_force_exit script, and that worked very nicely. I specified her original spawn point, and it made it look like she was re-merging with her tree. I'm very happy with the way the dryad quest turned out, but I'm speaking as the sort of person who really enjoys playing a good character. I don't know if my evil options will appeal as much to an evil character, because I don't enjoy playing that way, and I would hate to see someone actually take these actions. But the options are there. All the same, I think in future modules, I can improve things further with a denser packing of quest content into each area. Some of my areas are involved in up to three simultaneous quests, but others have only one. The size of the area matters, of course. But I love areas that have a lot of things to do and see, and a lot of interactions, with a good variety in quest types. Link to comment Share on other sites More sharing options...
Tchos Posted August 17, 2012 Author Share Posted August 17, 2012 Today I worked on an "event" at the climax of a quest. Again, the sort of thing that would ordinarily be handled by a cutscene, but which I'm doing in the freeform style as before. Also needed to import another icon for a quest item related to this event. The player must drink a special potion while within a certain proximity to a certain spot. At first I was going to try to use a trigger, and check to see if the player was standing in the trigger, but I didn't know how to do that without setting a variable, which seemed clumsy for this task. Since I had learned about this other command recently, I opted to use the GetDistanceToObject() function on the item's tag-based activation. Well, that didn't work, and I'm not sure why, but I'm guessing it's because it's checking the distance between the potion and the marker instead of the PC and the marker. That shouldn't make a difference, since the location of the PC should be the same as the location of the potion in the PC's inventory, but I switched it to use GetDistanceBetween() instead, which compares two specific objects, one of which I defined as the PC. That didn't work either, and after I put in some debug text to find out what was going on, I was getting a distance of 0.0f, which the docs said would happen if one of the objects was invalid. I rechecked my tags, and all seemed fine. Eventually the bit about environmental objects and objects with 0 HP not working with scripts came back to me, and I checked the object I had chosen as the marker. It was an environmental object. Fixed that, and the script worked...but with another problem. Somehow, it was getting a valid distance between me and the target even when I wasn't even in the same area. I used my debug text and was actually able to home in on the hotspot by watching the distance report get smaller and smaller until it reached the necessary proximity to fire the script, even though I was in a different area (Questland), and there weren't even any placeables around. So I determined that I needed to add a check to the script to see if the player is in the correct area first. That fixed it, but I wonder why it happened. I had a lot of trouble staying focused today, unless you count spending hours reading forum posts. The necessity of opening problem areas many times compounded this lack of focus, because the toolset crashed at least a dozen times during my troubleshooting and testing efforts. After adding that check, I needed to script a light on and off. Luckily, I had just read something on the forums about lights not being scriptable as easily as one would expect, due to losing their tags somehow during saving or loading. I found the workaround, and the light switching on and off works fine with GetNearestObject(OBJECT_TYPE_LIGHT,oTarget);. I learned today that setting the plot flag on a chest or a door, which I had been doing to prevent them from being accidentally destroyed by AoE, prevents them from being unlocked with the Knock spell. That's undesired behaviour. I'll revise the problematic items by giving them ample hit points instead. Next I needed to change the music during the event, and change it back afterward. I found the necessary commands (save, restore, set, start, and stop) in the ginc_sound include file, and imported the needed custom track. I'll have to stop there for the day, though, and script it into the event later. Link to comment Share on other sites More sharing options...
Tchos Posted August 19, 2012 Author Share Posted August 19, 2012 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. Link to comment Share on other sites More sharing options...
Tchos Posted August 20, 2012 Author Share Posted August 20, 2012 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. Link to comment Share on other sites More sharing options...
Tchos Posted August 21, 2012 Author Share Posted August 21, 2012 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. Link to comment Share on other sites More sharing options...
Tchos Posted August 22, 2012 Author Share Posted August 22, 2012 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. Link to comment Share on other sites More sharing options...
Tchos Posted August 23, 2012 Author Share Posted August 23, 2012 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. Link to comment Share on other sites More sharing options...
Cluas Posted August 24, 2012 Share Posted August 24, 2012 (edited) Hi Tchos. I enjoyed the read. It's good to hear that your computer survived the transplant :) Dust is bad for electronics, trust me... I always open up my case and check for dust inside, once a month or something. You see, if the fan collects too much dust, it suddenly gets stuck. No fan = Too much heat = Blue poisonous smoke I really like that you spend your time explaining what's going on with your work, thanks :thumbsup: Edited August 24, 2012 by Cluas Link to comment Share on other sites More sharing options...
Recommended Posts