675 réponses à ce sujet

[andysks]

I get it now. I need to write this script you provided void InitializeCompanions etc companion tags.
Name it, I don"t know... andy_initialize

Then add to my andy_mod_load

#include "andy_initialize"

and change line 138 with InitializeCompanions();

I also noticed, that my mod_load script has kinc_companions include commented out.
Do I need to change that, to maybe ginc_companions and not comment out?

In any case, after I do this, I just have to add a simple script OnClientEnter on any area that a companion should be spawned, with the spawn_* waypoint, and a command on the script to spawn the roster member.

When I need someone to spawn during a cutscene, use the same command as well.

Modifié par andysks, 09 novembre 2013 - 12:11 .

[andysks]

So I did some digging today on the MotB scripts. I need to write these things down, because I have no time to test them at the moment, and don't want to forget.

kinc_companion scripts.

States inside, amongst other things, the method for InitializingCompanions. It states the constant strings on tags and resrefs of companions. Then on the void InitializeCompanions, this line is put :

InitializeCompanion(TAG_SAFIYA, TAG_SAFIYA, RR_SAFIYA);

My problem before was that the function script for Initialization was compiling, but the mod_load with the include was telling me that InitializeCompanions is an undeclared identifier.

In MotB they have the k_mod_laod has the kinc_companion as an include, which has the ginc_companion as an include. The kinc_companion is filled with specific MotB commands, so I don't even need it. What I need I think, is a copy of the kinc_companion, altered a lot according to my needs as original kinc_companion did, and then include this copy on my custom mod_load.

I can only hope it works, since it was merely an epiphany, not tested yet . But my guess is that when Colors said he has a script for his party with commands, that is what he meant. Something like kinc_companion in MotB.

[ColorsFade]

andysks wrote...

Do I need to change that, to maybe ginc_companions and not comment out?

Aye. Im my haste to share some of this, I haven't gone into great detail about include files. 

Your custom script, andy_initialize, needs to include ginc_comapion. 

Then your modified k_mod_load script needs to inclue andy_initialize. 

Then it should work. 

However - just to be "safe" I would recommend renaming k_mod_load to something else. That is why mine is named dk_mod_load, to ensure my script doesn't conflict with anything else. Then just make sure all your areas are using that load script. 

[andysks]

OK, I think I am in a good way. I managed to make my scripts compile. The companion spawned, which in turn means that Initialization worked. However, she didn't follow out of the area, and when I entered again. she was not there, but re-spawned to her location. I guess it's one thing at a time.
It seems I am in a good direction, and start understanding more things about how the code works. Not just in these particular scripts, but generally in this language.

I also don't know how I did it, but when I opened the roster UI, she was grey and non selectable for removing. It could be a good thing, since I prefer them to be added just by a conversation.

And Colors, my big modified scripts like mod_load etc, are all named andy_mod_load etc .
Was mentioned in your guide about the wandering monsters.

In any case, this is the modified kinc_companion from MotB. It compiles, and initializes.
I just commented out or deleted the influence parts. is the part between the resrefs and tags constants, which is the companion string_resrefs:

Probably important thing commented out:

const int STR_REF_SAFIYA     = 185138;
const int STR_REF_GANN        = 185442;
const int STR_REF_OKKU        = 184853;
const int STR_REF_DOVE        = 185506;
const int STR_REF_ONEOFMANY = 185443;

And this is the script that compiles anyway.

#include "ginc_henchman"
#include "ginc_companion"
#include "ginc_object"
#include "ginc_ipspeaker"

//-------------------------------------------------
// Constants
//-------------------------------------------------


// Companion ResRefs
const string RR_ADOWARD     = "adoward";
const string RR_LEOKUL        = "leokul";
const string RR_WALORIN        = "walorin";
const string RR_NILEE        = "nilee";
const string RR_JARFED      = "jarfed";


// we'll always use tag as the roster name
const string TAG_ADOWARD    = "adoward";
const string TAG_LEOKUL        = "leokul";
const string TAG_WALORIN    = "walorin";
const string TAG_NILEE        = "nilee";
const string TAG_JARFED     = "jarfed";

// Companion add/remove
// --------------------------------------------------------------
void AddCompanionsToRoster();
void SpawnCompanion(string sTag, string sResRef);
void SpawnCompanions();
int RemoveAllCompanions( object oPC , int bDespawn = TRUE);

// adds all companions to the roster
// members in roster must still be added to party   
void InitializeCompanions()
{
    InitializeCompanion(TAG_ADOWARD, TAG_ADOWARD, RR_ADOWARD);
    InitializeCompanion(TAG_LEOKUL, TAG_LEOKUL, RR_LEOKUL);
    InitializeCompanion(TAG_WALORIN, TAG_WALORIN, RR_WALORIN);
    InitializeCompanion(TAG_NILEE, TAG_NILEE, RR_NILEE);
    InitializeCompanion(TAG_JARFED, TAG_JARFED, RR_JARFED);
}

// spawn all NX1 companions at their hangout
void SpawnCompanionRosterMembersAtHangout()
{
    // tags also serve as the roster name.
    SpawnNonPartyRosterMemberAtHangout(TAG_ADOWARD);
    SpawnNonPartyRosterMemberAtHangout(TAG_LEOKUL);
    SpawnNonPartyRosterMemberAtHangout(TAG_WALORIN);
    SpawnNonPartyRosterMemberAtHangout(TAG_NILEE);
    SpawnNonPartyRosterMemberAtHangout(TAG_JARFED);
}

// Success should return 0, or remaining number of companions on failure
int RemoveAllCompanions( object oPC , int bDespawn = TRUE)
{
    RemoveRosterMemberFromParty( TAG_ADOWARD,     oPC, bDespawn );
    RemoveRosterMemberFromParty( TAG_LEOKUL,    oPC, bDespawn );
    RemoveRosterMemberFromParty( TAG_WALORIN,         oPC, bDespawn );
    RemoveRosterMemberFromParty( TAG_NILEE,     oPC, bDespawn );
    RemoveRosterMemberFromParty( TAG_JARFED,     oPC, bDespawn );
   
    //return GetNumHenchmen( oPC );
    return (0);
}

This is just the first attempt. Was done really quick. But as I said, one step at a time .

The last thing I need to say, is that my Companions are campaign blueprints/recourses. Is that an issue? I have no idea. Also, every time I design a new one, I should go back to this script and add his strings etc I guess.

Modifié par andysks, 09 novembre 2013 - 05:01 .

[ColorsFade]

[quote]andysks wrote...

I also don't know how I did it, but when I opened the roster UI, she was grey and non selectable for removing. It could be a good thing, since I prefer them to be added just by a conversation.
[/quote]

That is because the initialization function makes set their CampaignNPC flag to TRUE, which makes them not selectable on the roster. When you get to the point in your story where you want to use the Roster GUI, then you flip the flags on the companions and make the CampaignNPC switch = FALSE. There's a function call to do that. 

[quote]andysks wrote...
And Colors, my big modified scripts like mod_load etc, are all named andy_mod_load etc .
[/quote]

Oh good! Perfect. 


[quote]

Probably important thing commented out:

const int STR_REF_SAFIYA     = 185138;
const int STR_REF_GANN        = 185442;
const int STR_REF_OKKU        = 184853;
const int STR_REF_DOVE        = 185506;
const int STR_REF_ONEOFMANY = 185443;
[/quote]

Those are just constant declarations. You don't need to comment then out. I wont' hurt anything if you do. 

[quote]
// adds all companions to the roster
// members in roster must still be added to party   
void InitializeCompanions()
{
    InitializeCompanion(TAG_ADOWARD, TAG_ADOWARD, RR_ADOWARD);
    InitializeCompanion(TAG_LEOKUL, TAG_LEOKUL, RR_LEOKUL);
    InitializeCompanion(TAG_WALORIN, TAG_WALORIN, RR_WALORIN);
    InitializeCompanion(TAG_NILEE, TAG_NILEE, RR_NILEE);
    InitializeCompanion(TAG_JARFED, TAG_JARFED, RR_JARFED);
}
[/quote]

To make life easy on myself, I make the tag, resRef, etc. all the same. 

[/quote]
The last thing I need to say, is that my Companions are campaign blueprints/recourses. Is that an issue? I have no idea. Also, every time I design a new one, I should go back to this script and add his strings etc I guess.

[/quote]

Making them campaign resources, IMO, is the correct way to do it. In the OC and MoTB, they are campaign resources as well. 

All it means when you make something a campaign resource is that it is stored in the campaign folder and available across ALL modules at any time. It's just a storage and access thing. If you are using something ONLY in a given module, then make it a module resource. 

When you went to add your companion, did they join your group? And then you said they didnt' follow you? 

Make sure your blueprint for your companions each has the proper script set. All companions should have the gb_comp_ scripts attached to them. Otherwise, yeah, they won't do anything. 

As for why they respawned in the inn when you went back in: Your OnClientEnter script to spawn them at the inn needs to make some checks. It needs to check to ensure the companions are not already in your group, for instance, otherwise it will respawn group members at their hangout. 

Here are two library functions I have in a library of mine called d_party. I do this in my onClientEnter script: 

#include "d_party"

PutCompanionsInPlace();

Then, here's the two relevant functions in the library: 

//////////////////////////////////////////////////////////////////////
// Puts non-party companions at their hangout spots.
// This should only be used in an area where we have set the hangouts,
// like an inn or stronghold. To be called in the OnClientEnter
// script slot.
//////////////////////////////////////////////////////////////////////

void PutCompanionsInPlace()
{	
	PutCompanionInPlace("wurdy");	
	PutCompanionInPlace("kayne");	
	PutCompanionInPlace("celeste");	
	PutCompanionInPlace("doxie");
}

//////////////////////////////////////////////////////////////////////
// Puts a non-party companion at their hangout.
// Should only be called by PutCompanionsInPlace()
//////////////////////////////////////////////////////////////////////

void PutCompanionInPlace(string sCompanionTag)
{	
	object oPC = GetFirstPC();		
	int bMetCompanion = GetLocalInt(oPC, "met_" + sCompanionTag);
		
	// If we haven't met the companion before, exit.
	if(!bMetCompanion)	
	{		
		SendMessageToPC(oPC, sCompanionTag + " has not been met yet");		
		return;	
	}			

	// If the companion isn't already in our party, then place them at 	
	// their hangout waypoint. There should only be one of these per module!	

	object oCompanion = GetObjectByTag(sCompanionTag);
	if(!GetIsObjectInParty(oCompanion))	
	{		
		string sHangOutWP = "hangout_" + sCompanionTag;
		SetHangOutSpot(sCompanionTag, sHangOutWP);
		SpawnNonPartyRosterMemberAtHangout(sCompanionTag);	
		SendMessageToPC(oPC, "spawning " + sCompanionTag + " at " + sHangOutWP);		
		SendMessageToPC(oPC, "GetHangOutSpot = " + 
		GetHangOutSpot(sCompanionTag));	
	}	
	else	
	{		
		SendMessageToPC(oPC, sCompanionTag + " is [IN] party!");
	}
}

So... let me walk you through the PutCompanionInPlace() method.

The first thing it does it check for a local variable on the PC named met_charname where charname is the tag of the companion. This tells me if we've ever met the companion yet, because if we have NOT met that companion yet in the story, we don't want to spawn them yet. And so the function exits if that variable is FALSE.

The next thing is does is check to see if the companion is in the party. The call to GetIsObjectInParty() is from ginc_companion, so my d_party library includes ginc_companion.

If the companion is NOT in the party, then we're going to spawn them at their hangout.

And so, with these two functions, all I ever have to do in my area's OnClientEnter script is call PutCompanionsInPlace(), and I'm done. Of course, the area itself has to have the hangout_ or spawn_ waypoints in it in order for it to work.

Good luck!

[andysks]

I got how it works. My companion spawned second time because the script didn't check for a variable.

I also have all three named the same. In the OC I believe they had the resref different, but I find it really convenient to all have the same name.

When the PC actually accepts them in the party, do you still need all scripts?
ga_roster_add_object
ga_roster_selectable
ga_roster_party_add
ga_reset_level

Or does the ga_roster_add_object got cared off through the mod_load and is not needed anymore?

[andysks]

It actually worked. She followed and everything. I can't believe it .
This was a big thing for me. I had placed companions, and I always had on the back of my head that it's not safe. Now my companion system will be better

To sum up.

Now they spawn, and are not forced.

Before they were forced because I didn't know how to transfer them, without placing multiple copies.
Also, the roster was available at all times, so a player could get a forced companion and then remove him.

Roster  UI  Unavailable

Once you accept a companion, he can only leave if you talk to him. I think this encourages the talk to companions. They all have a unique story to tell and a quest to give.

Hangout

Once they are kicked, or not accepted, depending on the story state, they will travel to the hangout, where you'll find them later. I haven't created one yet, but I will.
Depending on the story state, I will explain with an example.

You meet a companion in the very first quest, but have the option to say "I'd rather do it alone". If she travels to the hangout, which is two big areas away, and most important, in a city unreachable at the moment, and then decide that the quest is too tough  to solo, there would be no way to get her back.

Removing them from the party, and spawning.

Once removed via dialogue, I think I want two options. The companion will ask you, where do you need me to wait, in case you want me back? Each one of them, has a lfie of his own. For example, a druid, lives normally on the edge of a big forest. You can tell him, "Go home. I'll travel there some time and get you." Or, "Wait at the hangout."

I think I need two Global Variables for this, in order for the hangout to work.
1st case, sets it to 1.
2nd to 2.

The OnEnter of the hangout will check which companions have a 2, and spawn them accordingly.
Each area that a companion calls home, will check for an 1.

On the first time a companion needs to spawn, I set a local variable on the PC, since a global is not needed, and I need the Global for the other system. Once a companion is accepted, the local int is set, and won't spawn again. If removed, the other system takes place.

I also need to make a script for when party is full. Now the roster UI shows the companion grey, and maybe it's a good idea on the occassion of a full party that UI will become available.


It is some work to do. Need to set it up, which means go back to the prologue and make some work on it. But I think it's worth it.

Andy.

Modifié par andysks, 09 novembre 2013 - 08:18 .

[ColorsFade]

andysks wrote...

When the PC actually accepts them in the party, do you still need all scripts?
ga_roster_add_object
ga_roster_selectable
ga_roster_party_add
ga_reset_level

I have a script that handles adding a companion to the party and makes all the correct calls at one time. 

Here is the script. In my campaign I call it ga_dk_add_companion

#include "ginc_param_const"
#include "ginc_misc"

void main(string sCompanionTag)
{	

/////////////////////////////////////////////////////	
// Make the companion selectable on the Roster GUI	
// FROM: ga_roster_selectable				/////////////////////////////////////////////////////		SetIsRosterMemberCampaignNPC(sCompanionTag, 0);	SetIsRosterMemberSelectable(sCompanionTag, 1);			

/////////////////////////////////////////////////////	
// Add the companion to the party	
//FROM: ga_roster_party_add	/////////////////////////////////////////////////////		

object oPC = GetFirstPC();	
AddRosterMemberToParty(sCompanionTag, oPC);
		

/////////////////////////////////////////////////////	
// Set the companion's XP equal to that of the PC	/////////////////////////////////////////////////////	

object oCompanion = GetObjectByTag(sCompanionTag);	
int nXP = GetPCAverageXP();	
SetXP(oCompanion, nXP);	
ForceRest(oCompanion);
}

Then all you need to do is call ga_dk_add_companion("companionname") in the conversation node where you accept them into the party, and bingo. You're done.

[ColorsFade]

andysks wrote...

I think I need two Global Variables for this, in order for the hangout to work.
1st case, sets it to 1.
2nd to 2.

The OnEnter of the hangout will check which companions have a 2, and spawn them accordingly.
Each area that a companion calls home, will check for an 1.

The function call SpawnNonPartyRosterMemberAtHangout() will spawn the companion at their present hangout if you are in the correct zone (it won't spawn if you're not in the area at the time).

So, you don't need any variables for this, all you need to do is (I believe, I have not tested this) set their hangout spot in the conversation.

Thus, for the druid example, on the line of dialog where you elect to send her back to her home in the woods, you would make a call to ga_rm_set_hangout. You need to pass the companion name and the waypoint name to it. 

So: You want the druid to go home, you call ga_rm_set_hangout and you pass it the tag name of the companion and the tag name of the hangout. If your companion name was "kalera", for example, then I'd make the hangout something like, "kalera_home". It's verbose, but it's clear what it is. 

Now, if you want her to hang out at the inn, you lay down a waypoint there and call it "kalera_inn".

So: in the conversation node where you want her to go to the druid home in the first, you make two calls  (two ga_)

1) ga_rm_set_hangout("kalera", "kalera_home")
2) ga_rm_go_to_hangout("kalera")

Now, if you want her to go to the inn, on that conversation line you would call: 

1) ga_rm_set_hangout("kalera", "kalera_inn")
2) ga_rm_go_to_hangout("kalera")

Now, here's what happens:

When your OnClientEnter script runs when your PC enters the inn, if you have sent Kalera to her home in the forest, her hangout waypoint is in the forest. So the OnClientEnter script calls SpawnNonPartyRosterMemberAtHangout(), but it can't find the hangout waypoint in the current area, so it DOES NOT spawn her in the inn. Which is what you want. 

If you had set her hangout waypoint at the inn, she would spawn

And vice versa. If you set her hangout waypoint at the inn, and you go to the forest, and the OnClientEnter script fires, she won't appear. Again, SpawnNonPartyRosterMemberAtHangout() cannot find her hangout because it's not in the forest.. 

Clear as mud?

Hope it helps. 

The ginc_companion framework handles just about everything Andy. The ONLY private variable you ever need to track is whether your PC has met the companion. 

[andysks]

Companions

So after a couple of days of knowledge income, I was finally able to understand how the whole companion system works. So far, I thought you just place a guy, set a convo with the proper scripts and he joins. Yes, it will work. But now I saw that there are so many aspects behind this. I guess with the new system, not much will change gameplay-wise, but it's gonna be bug free and safer, and more comfortable to work with.

I had to take in so much information these last couple of days, I kept writting notes on an excel sheet. In the beginning I thought I have to play a lot with variables... I was wrong. The ginc_companion does the job.

In any case, the point is, that now my companions spawn instead of being placed. I had never read the part on ginc_companion that states we should do it like that.
Also, I was very confused with the term hangout. I thought it is the area itself that determines the hangout spot, while it's just the waypoint and the convo script.

What I mean is this.

If you say to the companion "Leave the party", and he says "Where should I go?"
You then can have as many destinations you want.
The inn
The bank
The park
The temple
etc.

These areas on their own, don't need much for a set up. Only one unique waypoint, which will be called from the convo line and two scripts: 1: ga_rm_set_hangout
                                                  2) ga_rm_go_to_hangout

So that's all.
Companions need to spawn with a client enter or through a cutscene only once/game, and after that if they get removed, they go to the proper hangout.
So if I want something similar to Sunken Flagon... I just set all hangout waypoints in there.
If I have 10 companions, and send them all to the same place through a convo, next time I enter this place, they'll wait me there.

If I am wrong in any of this, ColorsFade will correct me, I am certain of this .
But in any case I need to thank him and Tchos for their feedback here. Priceless!

Andy.

[ColorsFade]

Cheers! Good work Andy!

[andysks]

Journal

Last couple of days were days of learning and understanding. I made no progress, at least further in the story, but I like to thin that progress has been made generally, since I understood most of the aspects of the companion system, and almsot managed to make it exactly as I wanted. This has been eating me sine the beginning, sine I always knew I'll need to go back and fix these things, make them as I want them.

But going back wasn't a complete waste. As I opened some of the first areas, I had the opportunity to make them a bit better. Example, the first village, Elster.

Before



After



And some Aurora lights added in the distance.



The first picture is I believe not a very good quality, but I think the difference with the now is clear.

Also, since I was in the companion making business, I took the opportunity to create some more, and have them ready for later. So in addition to a Druid, Rogue, Cleric, Wizard, Sorcerer I got now a Ranger another Cleric and a Fighter. Equiped , with dialogues and ready to go.

The biggest decision I had to do these days though, was concerning the main plot. I realized that the player learns too much during the end of the prologue, and had to change some things.

Back to the companions.
I now have all companions with the option to decline them. However the dilema was that if someone declines the first two, and decides he wants them later, he has no access to the city he found them in. So I added a convo, where a guy tells the PC to finish all his business before he heads to the next area, because no one knows how much time will pass before he'll be able to come back. If the player still doesn't take the companions, and finds the next area too hard to solo, he got warned . But, in any case, I uncommented the line on my mod_load script that makes an autosave on world map transition. So even if the player cntinues with no companions, he can always load and take them.

[ColorsFade]

Your village looks good Andy.

I see other's screenshots and I always marvel and how good you folks are at it. I feel pretty weak in area design.

[andysks]

Well if it makes you feel better, I think that my areas look bad. So I guess we just think less of ourselves maybe .

[Arkalezth]

I think Elster was always at night time and blue-ish in my game. More than in that pic.

[andysks]

Could be more night than day since it's quite north. The first pic is very low quality hence the not blue-ish color. I hope you agree that now it looks better. I did some changes to the mountains as well, to the home the inn and the cave. I think from the crypts and forth everything is nice anyway. But the first module has the first areas I ever created, so a bit of correction more than a year later was needed.

I also added yesterday some more ambiance on Elster. Stuff like a hard working smithy, more barks and so on.

[kamal_]

andysks wrote...

But going back wasn't a complete waste. As I opened some of the first areas, I had the opportunity to make them a bit better. Example, the first village, Elster.

After

Winter wheat (the grass is a non-snowy version)?. Good logical use of the planks on the walkpaths, they would be there to cover up muddy areas.

I was reminded of the Waldheim prefab

[Calister68]

I love to model snowy areas, I used it extensively in a module I made a long time ago.
Snow, fog, bleak light allows you to set a nicely creepy atmosphere.

[andysks]

Some of the grass needs to be reworked yes. There are things I did when I made my first areas, that I didn't know how they could actually affect the general image. And it was so much information to absorb from tutorials, that some stuff like wheat in snow have happened .
I have searched through prefab areas a lot! But I never seen Waldheim. It looks really good. I like the texture work on the streets especially.

[andysks]

Hey Calister, good texture work as well. I think the snow is the most tricky to work with, since it can look very empty texture-wise. I mean, it is supposed to be empty, since people don't prefer heavy snow areas to settle, but in game it is a risk making an area really empty because of that.
When it comes to texturing, SGKs areas are like a tutorial. On his Ritual Sites, he has a snowy area, where he used 5 snow textures, all on one another, resulting in a very full and fluffy snow.

[andysks]

Journal

• Advancing the main quest

Today I did some... preparations let's say, in adition to many preparations I have already done, so that my work will be easier later when NPCs will need to populate and so on.

So I sat and created nearly 50 Weapons and Armor using the Barry the Hatchet pack, and Atom Armory. I have many places-locations in the world, where I want the NPCs to wear something special, as a tribe for example. They also help providing some lore for a world that is not Faerun, and people might be confused of what everything is. So anyway, with the work I did today, I don't need to create any items more for chapter 1, except specific drops, more powerful  boss drops.

I also created NPCs to populate these specific areas. For example some Elves for the Elven Forest in 4-5 variations, that use the Dagerknight's Elven Armor. Or some members of the Assassin Organization with the Ixion's Vagabond pack. Made them into blueprints, so that I just use them when I need to.

I also created shops, depending on the level that an area is about to be visited.

After all this, I made a plan in my head.

• Advance the main quest, up until the point where departure for the Outlands will happen. That is with no extra filling NPCs. Just story wise and key NPCs.
• Finish all side quests, still only with key NPCs.
• Go back to all these places, and fill them with NPCs, generic dialogues.
• Loot is put in place as the work progresses. I know the aproximate level that the PC will reach each place, so I can work depending on that.
• And finally, totally in the end of the work for chapter 1, place the companions, give them their quests and so on.

I chose this way, because companions still need to get initialized when the first module loads, and therefore if I place them now, I always need to go back to the script and add their prespective tags. Plus their hangout... generally. I think it's best if companions are done seperately, all together and not as I build an area that one might be in.

This progress brought me to a part of the story, where I had one of these "think and add things as you build".
Main quest brings you to a very secluded village at one point. As I was writting the cutscene conversation that happens uppon arrival, the NPC will help the PC, if the PC tells him the reason he is there.
You cannot go where you want, because you don't know where exactly it is. But they know.
I thought, I will offer an option to decline. Top secret eyes only and what not. And then it hit me.

If you choose to help the quest giver, he sends you on a quest to do something, like clearing a cave from gnolls... something like that, he will show you the way to the site that the main quest continues.
If you choose to decline, he says "Then I cannot help you if you give me no information. You can roam around our village, but stay out of these caves".

Now, the main quest is at hold, because you don't know the next location. If you choose to go to these caves though, you will find out that the NPC has a dark secret, and this is why he didn't want you to enter. Maybe you'll get a hint of that, from the villagers or something, so that you enter the cave no matter what. After that, the location for continueing is getting known.

So, co-operate : You get a quest to help a village
Not co-operate : You have to deal with the leader of the village that is actually a maniac of some short.

This offers options and replayability I think, and I will try to involve such options to other quests as well.

Well, that was enough for today, time to paly some guitar.

Andy.

[Friar]

Gosh you have really been trucking along! The more I read and see the more I look forward to playing your module.

Sometimes I wish we all had a clubhouse with computers set in a circle and we could check on each others progress with greater ease. But then maybe it wouldn't be as nice of a surprise when the final project is completed.

[andysks]

Sometimes I also think of this, but more like a project all together instead of checking each others progress .

[Tchos]

Are you saying that the NPC is friendly and wants you to go to the caves if you choose one thing, but he's a maniac who doesn't want you to go to the caves if you choose another thing? Is he secretly a maniac in both scenarios, but you only find that out if you make choice 2, or does he only become a maniac in choice 2? Or is this a different NPC that's a maniac?

[andysks]

The whole area has two types of convos, depending on this dialogue. The villagers will be spooky-secretive if you don't co-operate, because the leader is this maniac, and they are all in it together.
But if you choose to tell him the truth about why you are there, they will be helpful and glad that you help them out with the cave problem.
The quest giver, is involved somehow in both cases, as to what is in this cave.
But the OnEnter script of the cave will check for the variable given from your answer, and spawn the appropriate creatures in there.
Also, when you exit it, and if you cleared it (killed the boss), the previous area, village, has a possibility of being changed, depending on what happened in this cave.

I hope it made some sense .