Interesting. Thank you. I'll add another spot of texture in a discreet area, then, to bring up the total. I wouldn't want a psychedelic landscape either.
Also, I've gone ahead and put up the videos and screenshots of the island in a new blog post.
The Black Scourge of Candle Cove -- Tchos' development diary
Débuté par
Tchos
, juin 05 2012 10:59
Retour en haut
#77
Posté 20 juin 2012 - 01:40
Lugaid of the Red Stripes
-
- Members
- 955 messages
Those extra water tiles, because they're not walkable and don't have any interesting features, actually don't increase the file size significantly, so don't feel bad about including the extra marginal tiles.
You can also fiddle with the fog settings and area far clip to bring the horizon a little bit closer. Go to area properties, day/night cycle, and for each phase, expand out the fog settings. Fog start is how far away from the camera the haze begins, fog end is when the haze mostly obscures everything. Far clip is where the engine stops bothering to render objects. With your island taking up the center eight tiles, you could have a margin of eight tiles in either direction. Setting your fog end to 80m would then mean that at the shore of the island looking directly out to sea, you can just barely see all the way to the edge of the outer tiles.
You can also fiddle with the fog settings and area far clip to bring the horizon a little bit closer. Go to area properties, day/night cycle, and for each phase, expand out the fog settings. Fog start is how far away from the camera the haze begins, fog end is when the haze mostly obscures everything. Far clip is where the engine stops bothering to render objects. With your island taking up the center eight tiles, you could have a margin of eight tiles in either direction. Setting your fog end to 80m would then mean that at the shore of the island looking directly out to sea, you can just barely see all the way to the edge of the outer tiles.
#78
Posté 20 juin 2012 - 01:55
Tchos
-
- Members
- 5 042 messages
I have the far clip set to just beyond the edge of the max fog distance, which I set to make it so that you could barely see the town you came from. I wanted that to still be visible to give a better sense of location. It's a tricky balance getting it right for that and yet also not be able to see the edge of the map around the other directions. 
; Maybe I should have used the maximum area size after all.
; Maybe I should have used the maximum area size after all.
Modifié par Tchos, 20 juin 2012 - 01:56 .
#79
Posté 20 juin 2012 - 02:13
kevL
-
- Members
- 4 056 messages
Tchos wrote
... not sure how to do with conversation conditions. (Checking if A and B, or B and C are true).
if ((A && B) || (B && C))
{
// run this!
}- unfortunately under ConvoConditions we don't get to group stuff in parentheses ..... i think it would need a custom script. Or I guess you could do it with 2 nodes (same dialog, different conditions in each, the second acting as a fall through for the first)
I haven't tried it (yet) but Adinos' MDB manipulation tool can manipulate the X-Y plane ( then the model can be rotated about the Z-axis in the toolset ) -- tho it's a command-line tool ...Being able to rotate in all three axes would help a lot, too.
ps. Can i go live on your lighthouse?? with a big catapult, and a red dragon roost on the top .........
#80
Posté 20 juin 2012 - 03:22
Tchos
-
- Members
- 5 042 messages
Two nodes is how I did it for the other complicated conversation, which was also checking for multiple conditions (is the door unlocked? Have you already accepted the quest? Is the boss dead?) all of which could be fulfilled independently.
I'll have to try that manipulation tool. I know one place where I'll definitely need it.
I'll have to try that manipulation tool. I know one place where I'll definitely need it.
That depends on what you plan to do with that catapult!kevL wrote...
ps. Can i go live on your lighthouse?? with a big catapult, and a red dragon roost on the top .........
#81
Posté 20 juin 2012 - 03:55
Lugaid of the Red Stripes
-
- Members
- 955 messages
I don't often attempt multi-linear quests, but when I do, I like to lay out everything in the journal, with separate journal entries for each possible quest state, and then use custom scripts to move the plot from one state to another. That way, the conversation just has to check the journal entry, and your more complicated logic switches can be handled in a script.
Bitwise operations work well for this kind of thing.
For example, the quest could be laid out as follows:
1 - Learned about quest.
10 - accepted quest. (collect A, B, and C).
11- Got A.
12 - Got B.
13 - Got A and B.
14 - Got C.
15 - Got A and C.
16 - Got B and C.
17 - Got A, B, and C.
20 - Done with collecting.
21 - Ended quest by option #1.
22 - Ended quest by option #2.
Then you have an on-acquired script for your plot items that checks the PC's current quest status, and modifies it accordingly. This script can even set up a custom token that you can then use in the conversation. (i.e. "You still need to [collect A, B, or C]").
The important thing to remember is that there will be bugs, and it's a lot easier to squash a bug in a simple, repetitive script (especially if the journal tells you exactly where you are), than it is to trace back through reams of conversation logic trees and try to find what's missing.
Bitwise operations work well for this kind of thing.
For example, the quest could be laid out as follows:
1 - Learned about quest.
10 - accepted quest. (collect A, B, and C).
11- Got A.
12 - Got B.
13 - Got A and B.
14 - Got C.
15 - Got A and C.
16 - Got B and C.
17 - Got A, B, and C.
20 - Done with collecting.
21 - Ended quest by option #1.
22 - Ended quest by option #2.
Then you have an on-acquired script for your plot items that checks the PC's current quest status, and modifies it accordingly. This script can even set up a custom token that you can then use in the conversation. (i.e. "You still need to [collect A, B, or C]").
The important thing to remember is that there will be bugs, and it's a lot easier to squash a bug in a simple, repetitive script (especially if the journal tells you exactly where you are), than it is to trace back through reams of conversation logic trees and try to find what's missing.
#82
Posté 20 juin 2012 - 09:10
Tchos
-
- Members
- 5 042 messages
@Lugaid: I had to re-read that several times to be sure I understood the concept, and even so, I think my grasp on it is tenuous. It looks very workable, though. I had initially attempted to do something like that, as far as making separate journal entries for every combination of conditions, but when it came time to perform the actions and make the checks, it became confusing, and I ended up not using several of my journal entries and progressed the quest with other kinds of checks.
That problem I had earlier with the "once per game" condition was around the same time, though, so perhaps now that I can work around that I can also try the structure you recommend.
Custom tokens, you say... I had wondered about making custom tokens, but I never checked to see how it was done until you mentioned it here. I found the wiki page, and it looks doable. I might be able to use that somewhere. It says that they work in names (but not descriptions) of placeables, and do not work in NPC names or item names. What about NPC descriptions? I suppose their best use would be either in dialogue or in the quest journal. I'll have to experiment with that later.
That problem I had earlier with the "once per game" condition was around the same time, though, so perhaps now that I can work around that I can also try the structure you recommend.
Custom tokens, you say... I had wondered about making custom tokens, but I never checked to see how it was done until you mentioned it here. I found the wiki page, and it looks doable. I might be able to use that somewhere. It says that they work in names (but not descriptions) of placeables, and do not work in NPC names or item names. What about NPC descriptions? I suppose their best use would be either in dialogue or in the quest journal. I'll have to experiment with that later.
#83
Posté 20 juin 2012 - 05:00
kevL
-
- Members
- 4 056 messages
Lugaid's absolutely right that it's easier to script & debug a multi-path quest by using just one script, with multiple
//pick up an item, set an integer = 1
//give item to NPCa, set integer = 5
//give item to NPCb, set integer = 10
int iCase = // get integer ( or get current journal state )
if (blah de blah) iCase = de blah de
switch (iCase)
{
case 1:
// add journal entry.
// set custom tokens
// start conversation
break;
case 5:
// add journal entry.
// set custom tokens
// start conversation
break;
case 10:
// add journal entry.
// set custom tokens
// start conversation
break;
// etc.
default:
{
// SendMessageToPC "( filename ) broke !"
}
}
I trust it's obvious i'm just slopping something out to give the idea ..... 'integer' and 'journal state' are ideally the same thing, but don't have to be
switch(Case)statements. The Case can be defined by the journal state and/or a plot event, which can then be updated within the Case codeblock and where custom tokens may be set also. The overall script can be called from conversations or game events. Eg,
//pick up an item, set an integer = 1
//give item to NPCa, set integer = 5
//give item to NPCb, set integer = 10
int iCase = // get integer ( or get current journal state )
if (blah de blah) iCase = de blah de
switch (iCase)
{
case 1:
// add journal entry.
// set custom tokens
// start conversation
break;
case 5:
// add journal entry.
// set custom tokens
// start conversation
break;
case 10:
// add journal entry.
// set custom tokens
// start conversation
break;
// etc.
default:
{
// SendMessageToPC "( filename ) broke !"
}
}
I trust it's obvious i'm just slopping something out to give the idea ..... 'integer' and 'journal state' are ideally the same thing, but don't have to be
preemtive defense, honest. ;xThat depends on what you plan to do with that catapult!
Modifié par kevL, 20 juin 2012 - 05:04 .
#84
Posté 20 juin 2012 - 06:23
Tchos
-
- Members
- 5 042 messages
ThekevL wrote...
Lugaid's absolutely right that it's easier to script & debug a multi-path quest by using just one script, with multipleswitch(Case)statements.
I trust it's obvious i'm just slopping something out to give the idea
switch(Case)statement is a very new concept to me. I first saw them in the DA:O toolset and didn't understand what they were at all at the time, and only gained a rough understanding of their purpose about a month ago. All my scripts up to this point have used if/then statements, and I couldn't find any clear explanations on when it would be better to use
switch(Case), and why.
A friend just recently explained a reason why -- that it's cleaner, easier to read, and I guess by extension that makes it easier to debug. What I'm still not sure of is the when.
It's been on my list of things to try, but I haven't yet had the occasion!
This idea of using a kind of master script for a quest is new to me, too. When you say your example is just slopping something out, is that why it's setting journal entries and then starting a conversation upon acquiring an item? Are those supposed to be unrelated possibilities, or is there a situation where you'd want to do that? I can certainly see the utility of setting the tokens and updating the journal upon acquiring an item (or other condition)... Or is that for the purpose of checking to see that the conversation is using the tokens properly?
Very interesting possibilities, here, with this and Lugaid's suggestion.
#85
Posté 20 juin 2012 - 07:14
PJ156
-
- Members
- 2 982 messages
Saw the blog post Tchos, very interesting and I always like to watch other people working 
PJ
PJ
#86
Posté 20 juin 2012 - 07:39
kevL
-
- Members
- 4 056 messages
T: we're getting into massive abstractions here, what a/the script is actually doing depends on plot mechanics and personal preference ...
I just copy-pasted pseudo-codeblocks without knowing anything specific about your quests. One of the codeblocks could be fired upon acquiring an item, yes if it's arranged properly ( would need a tag-based onAcquire script, that then calls the quest-script here -- note you can do all that specific codeblock does in the onAcquire script, but this would defeat the purpose of a general script to handle a quest -- so just call the general script with the onAcquire script, eg. ). The notion of starting a conversation upon acquiring an item ... well, why not?
- alternately the info in such a 'dialog' could be put in the item's description or sent as a text message to the player. Or if an NPC is nearby he/she might actually have something to say when the item gets picked up. yada ..
switch/case is a lot like if/else.
switch/case is easier to understand when you come back to it a month later because everything's neatly ordered out, according to but a single integer ( iCase ). However, my belief is that an if/else script can ultimately be constructed more tightly and result in more efficient code -- but once yer dealing with 20 else clauses the brain tends to go a bit spongy. Personally i'll start with a switch/case, if what I'm thinking about looks *metaphorically* like a table or 2d array -- basically just a lookup table. But when I find that the compiler wants declarations & definitions to be outside the switch/case, i might switch to an if/else format,
I just copy-pasted pseudo-codeblocks without knowing anything specific about your quests. One of the codeblocks could be fired upon acquiring an item, yes if it's arranged properly ( would need a tag-based onAcquire script, that then calls the quest-script here -- note you can do all that specific codeblock does in the onAcquire script, but this would defeat the purpose of a general script to handle a quest -- so just call the general script with the onAcquire script, eg. ). The notion of starting a conversation upon acquiring an item ... well, why not?
- alternately the info in such a 'dialog' could be put in the item's description or sent as a text message to the player. Or if an NPC is nearby he/she might actually have something to say when the item gets picked up. yada ..
switch/case is a lot like if/else.
switch/case is easier to understand when you come back to it a month later because everything's neatly ordered out, according to but a single integer ( iCase ). However, my belief is that an if/else script can ultimately be constructed more tightly and result in more efficient code -- but once yer dealing with 20 else clauses the brain tends to go a bit spongy. Personally i'll start with a switch/case, if what I'm thinking about looks *metaphorically* like a table or 2d array -- basically just a lookup table. But when I find that the compiler wants declarations & definitions to be outside the switch/case, i might switch to an if/else format,
#87
Posté 20 juin 2012 - 08:53
kevL
-
- Members
- 4 056 messages
ps. Here's the theoretical result of a recent foray into Custom Tokens ( might as well throw it up here )
Say the PC has talked to Carl, then before starting the conversation a custom token can be set to "Carl" in the codeblock that pertains to the questline involving Carl:
but if the PC talked to Bob, use "Bob" in the codeblock for Bob:
Then insert the custom token in the dialog ( 9253, an arbitrary number, make sure it does not conflict with other tokens ) and either "Carl" or "Bob" will be displayed in the conversation. In the dialog itself I believe they look like this:
"I talked to <CUSTOM9253> and he says ..."
It really is a wonderful toolset, & if you haven't got NWN Lexicon v1.69 DL it now -- with 60 votes it has an ave. of 9.99 for a reason, 99.9% of it applies to NwN2
(well, more like 90%)
// Set the value for a custom token. void SetCustomToken(int nCustomTokenNumber, string sTokenValue);
Say the PC has talked to Carl, then before starting the conversation a custom token can be set to "Carl" in the codeblock that pertains to the questline involving Carl:
case 15: // talked to Carl int iToken = 9253; SetCustomToken(iToken, "Carl"); // start convo.
but if the PC talked to Bob, use "Bob" in the codeblock for Bob:
case 20: // talked to Bob int iToken = 9253; SetCustomToken(iToken, "Bob"); // start convo.
Then insert the custom token in the dialog ( 9253, an arbitrary number, make sure it does not conflict with other tokens ) and either "Carl" or "Bob" will be displayed in the conversation. In the dialog itself I believe they look like this:
"I talked to <CUSTOM9253> and he says ..."
It really is a wonderful toolset, & if you haven't got NWN Lexicon v1.69 DL it now -- with 60 votes it has an ave. of 9.99 for a reason, 99.9% of it applies to NwN2
(well, more like 90%)
#88
Posté 20 juin 2012 - 09:23
Tchos
-
- Members
- 5 042 messages
@kevL: Tag-based scripting took me a while to understand as well, but I understand all the item scripts now. Very convenient, actually. But when I was first looking at it, it was hard to understand how I could just create a script with a particular name, not attach it to anything, and it would just work on those events. So for a main switch script, I'd have item acquire (or whatever) include a line like ExecuteScript("my_main_quest_script"); after updating the journal or setting a variable somewhere.
I do have the NWN Lexicon, saved from my massive downloading binge, and I also have the Omnibus. I haven't sat down and read through them, though, just skimmed here and there.
@PJ: That reminds me of the old joke "I like work! I can watch it all day!"
I do have the NWN Lexicon, saved from my massive downloading binge, and I also have the Omnibus. I haven't sat down and read through them, though, just skimmed here and there.
@PJ: That reminds me of the old joke "I like work! I can watch it all day!"
#89
Posté 20 juin 2012 - 09:40
kevL
-
- Members
- 4 056 messages
re. ExecuteScript, in tag-based onAcquire.Tchos wrote...
So for a main switch script, I'd have item acquire (or whatever) include a line like ExecuteScript("my_main_quest_script"); after updating the journal or setting a variable somewhere.
the quirk here is you're going to have to pass a variable ( iCase ) along from the acquire-script to the quest-script; apparently it can be done with ExecuteScriptEnhanced() along with AddScriptParameter* functions -- but i haven't done it, so another way to do it is to have the acquire-script write a local_int somewhere and let the quest-script get it, before the switch/case begins. I'd be tempted to try the Enhanced method first tho,
i got a lot of the CustomToken info from the (rather long) tutorial in the Lexicon ... ( they work in journals and dialogs both )
ps. just let the onAcquire script call the quest script (and write a variable if ExecuteScriptEnhanced() isn't cooperating), and do all the journal entries and setting other variables in the quest script, that's the point. Ie, once you know the acquire-script is working, all the multi-path variables & functions that might need later tweaking are all in that one main script.
EDIT,
ah i see, yes i think we're on the same field now,... after updating the journal or setting a variable somewhere.
Modifié par kevL, 20 juin 2012 - 09:49 .
#90
Posté 20 juin 2012 - 10:43
Tchos
-
- Members
- 5 042 messages
I added the scripts, conversations, and waypoints needed to connect the new lighthouse island to the overland map, and tested the place out in-game for the first time. The fog settings looked just like they did in the toolset, so that was good. The docks were actually walkable, which I didn't expect. But the solid ground wasn't. So now I had to figure that out.
First I made a quick conversation to give a debug NPC that just lets me choose an area to which to teleport, so I didn't have to use the overland map every time.
I placed a walkmesh helper overlapping the dock and the ground, and after that I was able to walk off the dock onto the ground, but it stopped shortly after that, and a red texture was visible at certain angles from the walkmesh helper. Why it's not invisible, I have no idea. I guess you're supposed to delete it after you bake it, or something.
I suspected the slope of the hill was too steep, and that was stopping my walking progress, so I tried adjusting that. I figured out that the yellow outline is the one that indicates the walkable area, and not the nice, clean white outline that showed up after I used the walkmesh cutter. One thing that confuses me is that there are two different yellow outlines, depending on whether I have the "baked" button active or not. The non-baked one looks fine, but not the baked one.
I baked, adjusted, baked, etc., etc. I tried adding stairs and walkmesh helpers. I discovered one thing that was probably causing a lot of the trouble, and that was that some of those rock placeables were blocking off the walkmesh, so I changed those to environmental objects. The bit between the dock and land continued to be a problem, and I spent a very long time with it. I used stairs to help it out, but it remained more finicky than a spoiled cat. It's like the troubles I was having in the Dragon Age toolset with the shadow maps.
"This can be a lengthy process," it tells me. Yeah, but mainly because of how many times I had to retry it. Maybe I'm missing something fundamental.
Finally, I got an acceptable walkmesh. Unbelievable. It still has an inexplicable gash in one part, but there's plenty of room to navigate around it, so it won't stop the player from getting past, at least. Not optimal, but I think it would be easier to make it worse at this point, rather than better.
I spent nearly the whole day on that task. It was almost a relief to go back to working on conversations.
Looking at it now, I don't think I need to actually test for as many conditions in this one as I thought I would. I really only need to check to see if either of the two alternate end entries in the journal for the merchants have been reached. The mayor's quest, which has only one resolution, can do a double-check instead of this one doing a triple-check.
I finished the fairly simple "remind me" branch and "I've reconsidered your offer" branch, and that left the "quest reward" branch.
Another probably unnecessary complication in addition to the checks from earlier in this conversation is that I decided to offer three possible rewards for following one of the two branches in the merchant quest, but you'll have to be a master at one skill to get one of those options, and a master of two skills (both related) to get both of the options. Everyone else will just get the default. This is part of my overall design goal of including bonus content for non-combat skills. Of course, since you can use any of your party members to do the talking with SoZ dialogue, you're five times more likely to be able to get this bonus than with non-party-chat.
Anyway, that means creating 3 "contract" quest items instead of 1. If I had known about custom tokens before, I might have wanted to approach this differently, and create only one contract with a custom token in its description to describe the different rewards, but apparently custom tokens don't work in item descriptions anyway. Besides, having 3 versions of the contract means I can check the inventory later to determine which reward to give, as an alternative to using the journal.
Before I do that, I'm going to try installing some more toolset plugins, like an icon viewer and an item creation wizard.
First I made a quick conversation to give a debug NPC that just lets me choose an area to which to teleport, so I didn't have to use the overland map every time.
I placed a walkmesh helper overlapping the dock and the ground, and after that I was able to walk off the dock onto the ground, but it stopped shortly after that, and a red texture was visible at certain angles from the walkmesh helper. Why it's not invisible, I have no idea. I guess you're supposed to delete it after you bake it, or something.
I suspected the slope of the hill was too steep, and that was stopping my walking progress, so I tried adjusting that. I figured out that the yellow outline is the one that indicates the walkable area, and not the nice, clean white outline that showed up after I used the walkmesh cutter. One thing that confuses me is that there are two different yellow outlines, depending on whether I have the "baked" button active or not. The non-baked one looks fine, but not the baked one.
I baked, adjusted, baked, etc., etc. I tried adding stairs and walkmesh helpers. I discovered one thing that was probably causing a lot of the trouble, and that was that some of those rock placeables were blocking off the walkmesh, so I changed those to environmental objects. The bit between the dock and land continued to be a problem, and I spent a very long time with it. I used stairs to help it out, but it remained more finicky than a spoiled cat. It's like the troubles I was having in the Dragon Age toolset with the shadow maps.
"This can be a lengthy process," it tells me. Yeah, but mainly because of how many times I had to retry it. Maybe I'm missing something fundamental.
Finally, I got an acceptable walkmesh. Unbelievable. It still has an inexplicable gash in one part, but there's plenty of room to navigate around it, so it won't stop the player from getting past, at least. Not optimal, but I think it would be easier to make it worse at this point, rather than better.
I spent nearly the whole day on that task. It was almost a relief to go back to working on conversations.
Looking at it now, I don't think I need to actually test for as many conditions in this one as I thought I would. I really only need to check to see if either of the two alternate end entries in the journal for the merchants have been reached. The mayor's quest, which has only one resolution, can do a double-check instead of this one doing a triple-check.
I finished the fairly simple "remind me" branch and "I've reconsidered your offer" branch, and that left the "quest reward" branch.
Another probably unnecessary complication in addition to the checks from earlier in this conversation is that I decided to offer three possible rewards for following one of the two branches in the merchant quest, but you'll have to be a master at one skill to get one of those options, and a master of two skills (both related) to get both of the options. Everyone else will just get the default. This is part of my overall design goal of including bonus content for non-combat skills. Of course, since you can use any of your party members to do the talking with SoZ dialogue, you're five times more likely to be able to get this bonus than with non-party-chat.
Anyway, that means creating 3 "contract" quest items instead of 1. If I had known about custom tokens before, I might have wanted to approach this differently, and create only one contract with a custom token in its description to describe the different rewards, but apparently custom tokens don't work in item descriptions anyway. Besides, having 3 versions of the contract means I can check the inventory later to determine which reward to give, as an alternative to using the journal.
Before I do that, I'm going to try installing some more toolset plugins, like an icon viewer and an item creation wizard.
#91
Posté 21 juin 2012 - 12:22
Dann-J
-
- Members
- 3 161 messages
For outdoor areas, I prefer making the existing terrain mesh triangles walkable or non-walkable, rather than use lots of walkmesh cutters. It's a much coarser approach, but the resulting baked walkmesh tends to behave itself more.
Every time you put down a walkmesh cutter, you are introducing new polygons into the terrain mesh when you bake. This can result in long thin slivers appearing, or even large areas that end up completely unwalkable if too many nearby walkmesh cutters (or static non-environmental placeables) are competing with each other.
Every time you put down a walkmesh cutter, you are introducing new polygons into the terrain mesh when you bake. This can result in long thin slivers appearing, or even large areas that end up completely unwalkable if too many nearby walkmesh cutters (or static non-environmental placeables) are competing with each other.
#92
Posté 21 juin 2012 - 12:27
Tchos
-
- Members
- 5 042 messages
Are you saying that I could just paint over that triangle in the middle of the road with the "walkable" brush, and it would work? I admit, I didn't even see those tools until I got it to this point.
#93
Posté 21 juin 2012 - 12:50
kamal_
-
- Members
- 5 240 messages
Yes, the walkable/unwalkable brushes override the toolset's determination of terrain being walkable or not. You could brush a sheer cliff into walkability, or just make an unwalkable patch of ground. The unwalkable brush is a bit better for performance than a walkmesh cutter (but less accurate). Using the brushes to smooth out the walkable/unwalkable triangles helps pathfinding in the areas with jagged triangles as well.Tchos wrote...
Are you saying that I could just paint over that triangle in the middle of the road with the "walkable" brush, and it would work? I admit, I didn't even see those tools until I got it to this point.
#94
Posté 21 juin 2012 - 06:08
PJ156
-
- Members
- 2 982 messages
For future reference you might consider having the dock an environmental object and using a walkmesh helper to cover it all. Make the land as flat as possible where the join is to be and the bake may well go more smoothly. You can delete the helper afterwars but make sure you do bake again
PJ
PJ
#95
Posté 21 juin 2012 - 10:55
Tchos
-
- Members
- 5 042 messages
I'll certainly take those tips into account on my next adventure into area creation.
One of the plugins I installed was the Sin plugin, which does a lot of things that I could already do with the Usability plugin, but which also includes an "item lab". I just hope it doesn't interfere with any Usability keys. The main reason I want to use a plugin instead of just doing it in the item properties window is that I find that properties window rather chaotic and hard to read, and a plugin like this puts just the relevant settings into a nice, neat window.
Another one I installed was Lazjen's Icon Viewer, but I couldn't find any version compiled for the final toolset version, and although it worked anyway with the toolset config file, its functionality was either already duplicated by another plugin (maybe Usability again), or was built into the toolset later in the icon dropdown picker.
Then I re-read the documentation on item creation, and set about making the quest items.
Does anyone have an opinion regarding theplot cursed flag? Is it a good thing, a convenience, a necessary evil, or an unnecessary annoyance? I generally find it an annoyance as a player. It's mainly an annoyance when I just want to move them to a different character or put them in a bag of holding to unclutter my inventory, and it won't let me do that. It's also annoying on the occasions when they're not removed from the inventory when the quest is finished. Kaldor Silverwand's Context Menu Additions mod lets me get around that as a player, dropping all items, flagged or not, and allowing me to pick them up with a different character if necessary.
Should I trust the players to understand that if they drop, destroy, or sell a quest item, they won't be able to finish the quest?
I tried out Grinning Fool's Creature Creation Wizard to create the questgiver from the Merchants' League, but it crashed the toolset when I was scrolling through the appearances. When I restarted the toolset, I found that the quest item I had created had lost its name, description and icon choices. This is the third time I've created this item. I thought item properties are saved immediately as you edit them! I'm glad I saved the description externally last time...
I installed a couple of new heads for use on NPCs -- just the ones I intend to use immediately. I can add more if I need them. These are actually NPC heads, but using this package allows me to outfit them as I want, rather than being stuck with the NPC's appearance, clothing and all. I think Garius has a very good head, but his outfit is ridiculous, and unfortunately this pack doesn't seem to include his head, but there were several good ones to choose from for an older man. If only there was nearly as much variety for the non-human races!
My modding was cut short due to an unexpected guest to entertain.
One of the plugins I installed was the Sin plugin, which does a lot of things that I could already do with the Usability plugin, but which also includes an "item lab". I just hope it doesn't interfere with any Usability keys. The main reason I want to use a plugin instead of just doing it in the item properties window is that I find that properties window rather chaotic and hard to read, and a plugin like this puts just the relevant settings into a nice, neat window.
Another one I installed was Lazjen's Icon Viewer, but I couldn't find any version compiled for the final toolset version, and although it worked anyway with the toolset config file, its functionality was either already duplicated by another plugin (maybe Usability again), or was built into the toolset later in the icon dropdown picker.
Then I re-read the documentation on item creation, and set about making the quest items.
Does anyone have an opinion regarding the
Should I trust the players to understand that if they drop, destroy, or sell a quest item, they won't be able to finish the quest?
I tried out Grinning Fool's Creature Creation Wizard to create the questgiver from the Merchants' League, but it crashed the toolset when I was scrolling through the appearances. When I restarted the toolset, I found that the quest item I had created had lost its name, description and icon choices. This is the third time I've created this item. I thought item properties are saved immediately as you edit them! I'm glad I saved the description externally last time...
I installed a couple of new heads for use on NPCs -- just the ones I intend to use immediately. I can add more if I need them. These are actually NPC heads, but using this package allows me to outfit them as I want, rather than being stuck with the NPC's appearance, clothing and all. I think Garius has a very good head, but his outfit is ridiculous, and unfortunately this pack doesn't seem to include his head, but there were several good ones to choose from for an older man. If only there was nearly as much variety for the non-human races!
My modding was cut short due to an unexpected guest to entertain.
Modifié par Tchos, 22 juin 2012 - 01:38 .
#96
Posté 22 juin 2012 - 01:06
Dann-J
-
- Members
- 3 161 messages
The 'cursed' flag is the one that prevents you dropping or transfering items. The 'plot' flag on items really only prevents you from being able to sell them.
Cursed items can be a real pain to work with, since you can't pick them up from corpses or containers, and it's not easy to get rid of them in an exported character (like the recipe books in SoZ). Setting items to 'plot' is a handy way of preventing players accidentally selling important items though (but they can still choose to drop them).
Cursed items can be a real pain to work with, since you can't pick them up from corpses or containers, and it's not easy to get rid of them in an exported character (like the recipe books in SoZ). Setting items to 'plot' is a handy way of preventing players accidentally selling important items though (but they can still choose to drop them).
#97
Posté 22 juin 2012 - 01:38
Tchos
-
- Members
- 5 042 messages
Okay, then the question should be about the cursed flag instead of the plot flag. You would say "don't use it"?
#98
Posté 22 juin 2012 - 03:58
kevL
-
- Members
- 4 056 messages
.. unless it's cursed
Or something really really important like an object used to store game variables on, or the box of insects that PC has to feed the boss in the endgame .... Get/SetItemCursedFlag prob. work okay ... go with what you'd want, T. yeh
Or something really really important like an object used to store game variables on, or the box of insects that PC has to feed the boss in the endgame .... Get/SetItemCursedFlag prob. work okay ... go with what you'd want, T. yeh
#100
Posté 22 juin 2012 - 09:50
Tchos
-
- Members
- 5 042 messages
Today I debugged the league conversation and created more quest items. I like items. They're great flavour.
My experience seems to confirm that items don't get saved unless you specifically save the entire module, whereas with other things like conversations and scripts, there are ways of saving just that part you were working on. I had several unexpected occurrences. It seemed that when I changed an item, it didn't update the item that I had placed in a container, because it still contained the old version of that item.
I looked around for a standalone item creator that I could use outside of the toolset to make it more convenient, but couldn't find any.
I imported some new icons for some of my items, and spent a while learning the icon format and getting the proper frame, and experimenting to see which formats and modes would work. The tutorial says it needs to be a 40x40 32-bit TGA with alpha channel transparency. TGAs are very large and inefficient, especially in 32-bit. I also don't like the tiny 40-pixel images, and like the idea of building in support for UI mods like the bigger inventory mod which increase the size of the inventory icons 200%.
I made 4 icon images with different settings to apply to duplicates of the same item to see which ones would work. One was a control image made according to specifications, another was a PNG, another was a 64x64 TGA, and another was an 8-bit TGA with no alpha channel. The only transparency I see in the official icons is in the frame corners to make them slightly rounded. Considering those icons are usually on a dark background, I don't think the alpha channel is really necessary.
When I tested the new icons, I found that PNG doesn't work, but 64x64 does (presumably any size is resized to fit the UI), and 8-bit also works. In fact I used 64-colour indexed TGAs in some cases, and it still worked.
I thought that leaving out the alpha channel would make the lack of transparent corners visible when I moved the icons around over light surfaces, but surprisingly enough, they were in fact rounded! Perhaps the alpha transparency for icons is actually handled by some aspect of the UI, and the icons don't need alpha channels at all! In any case, this brought the file size of my icons down to 3.74k, despite the larger dimensions, which is half the size of the vanilla icons.
So now I've added a nwn_icons 2da to my hak, and created all the items necessary for the main quest.
The past few days have been relatively unproductive. I'll have to get back on track.
My experience seems to confirm that items don't get saved unless you specifically save the entire module, whereas with other things like conversations and scripts, there are ways of saving just that part you were working on. I had several unexpected occurrences. It seemed that when I changed an item, it didn't update the item that I had placed in a container, because it still contained the old version of that item.
I looked around for a standalone item creator that I could use outside of the toolset to make it more convenient, but couldn't find any.
I imported some new icons for some of my items, and spent a while learning the icon format and getting the proper frame, and experimenting to see which formats and modes would work. The tutorial says it needs to be a 40x40 32-bit TGA with alpha channel transparency. TGAs are very large and inefficient, especially in 32-bit. I also don't like the tiny 40-pixel images, and like the idea of building in support for UI mods like the bigger inventory mod which increase the size of the inventory icons 200%.
I made 4 icon images with different settings to apply to duplicates of the same item to see which ones would work. One was a control image made according to specifications, another was a PNG, another was a 64x64 TGA, and another was an 8-bit TGA with no alpha channel. The only transparency I see in the official icons is in the frame corners to make them slightly rounded. Considering those icons are usually on a dark background, I don't think the alpha channel is really necessary.
When I tested the new icons, I found that PNG doesn't work, but 64x64 does (presumably any size is resized to fit the UI), and 8-bit also works. In fact I used 64-colour indexed TGAs in some cases, and it still worked.
I thought that leaving out the alpha channel would make the lack of transparent corners visible when I moved the icons around over light surfaces, but surprisingly enough, they were in fact rounded! Perhaps the alpha transparency for icons is actually handled by some aspect of the UI, and the icons don't need alpha channels at all! In any case, this brought the file size of my icons down to 3.74k, despite the larger dimensions, which is half the size of the vanilla icons.
So now I've added a nwn_icons 2da to my hak, and created all the items necessary for the main quest.
The past few days have been relatively unproductive. I'll have to get back on track.
