676 réponses à ce sujet

[andysks]

KevL:  The conversations are esential there. They provide some insight on the companions. Although they are not big, they are like 3-4 nodes or something. I could make it a speak string, only if there is a way to queue the nodes one after another. Kinda like in Dragon Age when you were walking and the companions were talking in the meanwhile with floating texts. But I've never seen such a thing here.

 

 

I think the armoire set to lock and key require should solve this. Same as doors when they have the gp_talk_door on their fail to open. I'll try the same way here. Tsongo this is also a way of course . Or in general, just use a placeable that doesn't have a default behavior.

[Dann-J]

Forget the scripting stuff.. Change a normal placeable's appearance into an armoire then use the generic gp_talk object in the on used bit and give it a conversation.

 

Simply removing its inventory will change a container into a 'normal' placeable.

 

I use chests set into the floors of houses as trap doors. An OnUse script opens it (PlayAnimation), waits 1 second, jumps the players to the cellar, then closes it again (another PlayAnimation).

[Eguintir Eligard]

There was some universal blueprint changer for the toolset. I don't know that it worked though because I still had to replace items in game anyway by hand

[kamal_]

Simply removing its inventory will change a container into a 'normal' placeable.
 
I use chests set into the floors of houses as trap doors. An OnUse script opens it (PlayAnimation), waits 1 second, jumps the players to the cellar, then closes it again (another PlayAnimation).

In my experience the Has Inventory property must be unchecked or it will be a usable but empty inventory.

[andysks]

That did it kamal. I thought the script (gp_talk_object) will bypass the Has inventory, but as it turned out, not. Thanks a lot. The idea for such convos came from Dragon Age as well. Many cowards hid in the closets and I found it quite realistic .

[Eguintir Eligard]

Are your cowards coming "out" of the closet?

[andysks]

Journal Update

 

The time for this test finally arrived, and I couldn't be more excited. The ammount of work is truly immense.

What people will test is the work of the last 2,5 years.

About 80 areas on these chapters.

47 journal entries.

About 30 can be completed during this test.

10 companions so far.

Reach level 10ish.

About 125.000 words on dialogues.

 

During my own test, I was really surprised that the recent stuff went almost completely smooth. And I realized that I still fix lousy work from the beginning, where I was learning how to use the toolset. But in my head, my mentality while working is "A bug fixed, is a bug less". So even if I find 100, one by one they'll get fixed.

 

Around 6 months ago I sent an image of my ToDo list to PJ, and his reply was "That is a lot of work you have there". All gone now. More will get added from the reports I get these days, and these will get erased as well wíth time.

 

This is also the first time a player that is not me, the builder, will see Chapter 1 and 2, and not just the prologue. This makes me nervous of course. For I never released anything, and only a couple of people have played the prologue so far. We'll see how this goes. It is zipped as I write this, and I think the main reason I update my journal is to get my mind a bit of the fact that I actually send it later today .

 

I know it's only a test, and not the official release... but still. The work done so far is just too much that even this makes me nervous.

 

Next update, will be on how good this thing went. I hope all goes well .

[Dann-J]

In my experience the Has Inventory property must be unchecked or it will be a usable but empty inventory.

 

That's what I meant by 'remove its inventory'. I should have positively modified my clarity quotient.

[andysks]

Journal Update

 

I have to admit that I have learned a lot over the past days. About how some script functions work, and on how to make my work less buggy... so to say.

One of my testers, is playing a spellcaster. Naturally, he doesn't want to lead with him. So he let his companions take the first shots while he was back there shooting arrows and spells. I always play a melee. Fighter, Paladin, Cleric... anything. But I always feel comfortable leading on. So my scripts never failed, or the conversations always got the expected result. But to this tester, not.

it doesn't break his game so far, but because he is a builder he suspects where things went wrong and figured the solution. But first things first.

 

I used to use the node option to update a journal. What I found out is that this updates the journal for the speaker. Which is fine for the OC, because the companions can never initiate dialogue. Now the problem is, that the speaker, PC or companion has a journal. Yes. Even if it shows the same when we press "j", it's different. I'm thinking, go figure. But still. This leads to the problem.

 

If I talk to NPC1 with my PC and get a journal entry, then go somewhere to check with gc_journal but talk with my companion the script will return FALSE. Because the companion didn't get the entry, my PC did. Long story short (best expression ever), I have to go back and erase the node option and add the ga_journal to update for all players. Major delay but a very stable method for updating the journal and be safe.

 

The other thing, was trigger related. I was confussed I guess, because of the many functions for PC. GetPCSpeaker, GetFirstPC etc.

Trouble showed with this one, which was created by Lilacs.

	// Get the creature who triggered this event.
object oPC = GetEnteringObject();

// Only fire for (real) PCs.
if ( !GetIsPC(oPC) || GetIsDMPossessed(oPC) )
return;

// Set a local integer.
SetLocalInt(oPC, "shipb", 1);

What went wrong, is that the companion entered, as PC, and got the local int. Then an NPC checked it in a conversation, but another companion was doing the talk and the local int of course returned false. Then I had a talk with KevL who is proving to be quite a mentor in these things , and he told me

 

"On to the technical aspects: GetIsPC() does not get isPC ....

it gets "is player controlled" -- that's an unfortunate carry-over from NwN."

 

Brain all over the wall.

 

All this led to the conclussion that a script should start with:

    object oPC = GetEnteringObject();
    if (!GetIsPC(oPC))
        return;

That means that it will fire no matter what enters it that is player controlled. But we don't want to leave it like that, for it will add the variable to the EnteringObject, being a companion of anything. Redefining the PC after that solves that.

oPC = GetFirstPC();

Because GetFirstPC(TRUE) - gets only the character(s) that player(s) really entered the Game with. As KevL informed me. So by redefinning, I am certain that the script runs, adding variables and all to the main character.

 

I guess this is more or less known to be honest. I just had to write these things down as a reminder to myself, and maybe as a hint to others like me who might make the same mistakes. Clicking the box on an NPC that says CanTalkToNonPlayerCreatures is fun. It doesn't teleport our hero where he doesn't want to be. But if one is not careful it leads to problems. Companions are PCs. And therefore everything we add to the PC, or check him for, applies to them as well.

 

A lot of work to do. Fixing all of these scripts, conversations and journals... I expect to take me weeks. But at least I won't bang my head against the wall in the future when someone tells me "Hey, why isn't this guy completing the quest?", or anything similar .

[Eguintir Eligard]

Couple quick tips.
In campaign properties check "keep journal synced to leader". It may make all those journal changes I relevant. Everyone s journal is identical then.

Then

Whenever you use GetFirstPC(false) it returns the currently controlled character even if not the pc made one. Whoever you have active currently is returned.

[andysks]

Couple quick tips.
In campaign properties check "keep journal synced to leader". It may make all those journal changes I relevant. Everyone s journal is identical then.

Then

Whenever you use GetFirstPC(false) it returns the currently controlled character even if not the pc made one. Whoever you have active currently is returned.

 

I checked that EE, and I was already synced it to TRUE. That means that something else happened there and you couldn't talk after the lizards. For the journal should have been synced. I guess...

 

As for the GetFirstPC, I always use it to TRUE. It could be another way to be certain a trigger will fire if you start with FALSE, but then redefine on TRUE, if you want the script to have effects on the main PC I guess.

[Eguintir Eligard]

To solve most of your problems false should be your default. If you do not specify anything it defaults to true which is bad for your campaign. Just keep in mind that if its something other than talking it will use whatever the currently controlled object is which could income include pets or some familiar.

[kevL]

GetFirst/NextPC

- if you want the true PCs, use TRUE
- if you want the players' currently controlled characters, use FALSE


what should be used depends on the specific context ...

[andysks]

To solve most of your problems false should be your default. If you do not specify anything it defaults to true which is bad for your campaign. Just keep in mind that if its something other than talking it will use whatever the currently controlled object is which could income include pets or some familiar.

Yes exactly. I got the grip now. It was mainly problems with the stock ga_local_int. Since companions aer available to talk to NPCs as you saw, they were getting the variables since I was putting it on the $PC. Now I know and I fix it using some more stable objects like the module.

 

Question which comes out of me not playing too often. Area transitions and OnEnter scripts for areas... no matter who makes the transition, the created PC always enters first right? And he is the controlled one.

[Dann-J]

I assume the first PC is the first loaded into the area (in a single player game), however whatever party member you were possessing when you made the transition should still be the party member possessed when you enter the area.

[Eguintir Eligard]

Another thing I noticed Andy, you have a bit of overeliance on variables with larger gaps in journal updates which makes it more complex.

Example:
Quest given by npc: knock on three doors and run away then come back and see me!

From your style so far it seems like you would give them a journal to start the quest but not update the journal again until all three are done and use variables to keep track.

I instead: use no variables and update the whole party's journal after each door is Knocked on. No variables. Not only is this much less to check and less prone to bugs, the player gets more frequent feedback and knows where they left a quest after returning from a break from playing.

[Tchos]

He's probably using my system for that, and it's designed to use custom tokens to update the journal on each collection, as long as those custom tokens are put in the journal.

[Eguintir Eligard]

His style of journal updating does not resemble yours in anyway. It's very thin on journal updates, which isn't too bad as a player once you are used to it but it is causing him to have to check more things than he should have to.

[andysks]

Hi EE. Which quest do you mean? I am not sure if you mean one with custom tokens.

[Eguintir Eligard]

Many quests. It is just a general concept. If you play the original games for example, you will notice journal updates occur at many (usually all) quest steps/stages.

 

It may be your style, you might prefer to just give a quest, one journal entry explaining the things to do, and not update it again until the player returns with it fully done. That's fine, but it means a lot of variable handling for you rather than just being able to check the journal to see all of the different requirements the player has completed in the quest.

 

I will try to give another example.

Typically in the OC or many player campaigns, if you are given the quest below:

 

• You enter Ye Olde Pub (Ye Old Pube?)
• Fatso the Barkeep says: I have made a few enemies. Kill them all. Grunty the Orc, Stinky the Troll and Fartsmeller the Imp. When you are done I need you to also get a shipment of Pies from the local bakery.

 

From what I have seen in return of the exile, I would get a quest journal entry saying to do all of the above. And then I would do it, but the journal doesn't change until I am done the quest entirely, then I go back and tell Fatso the Barkeep all I did and the quest ends. So if you are not using journal entries for each step you must be using variables. That's tricky plus you can not see if they are working without using debug all the time.

 

I am suggesting that a quest start with a journal entry for all the above, then an entry for killing Grunty the Orc, another for Stinky the Troll and another for Fartsmeller the Imp. And then one more for the pie. Then an entry that says you have done all that you had to do, and can now go back to Fatso the Barkeep at Ye Olde Pub to report your success. And you use all those entries to track the quest and check its status rather than variables.

 

 

Make sense?

[andysks]

Perfect sense. I would think that this may cause overwriting higher entries though. Of course, nobody says one cannot just give many quests each for killing the creatures an individual one. To keep it clean.

some of mine you are correct. They are intentional. The reason is simple. I thought of it like that.
NPC says find me these locations where this flower grows. One journal entry. Then the player has to think "ah this guy wanted this", even if one location turns up 10 hours pf gameplay later.
When I play I like to think a bit and I don't want everything on my journal. I guess both ways can be implemented and enjoyable. Just one needs work on variables and might be prone to bugs as you said.

[Eguintir Eligard]

Then you just have to work out the variable bugs then if you want to maintain a less hand-holding journal. Which is not a bad thing if you want that style. Baldur's was more that way.

[Dann-J]

Not putting things in the journal can be detrimental if you stop playing for a few days, and you can't remember what you've found where or who said what. As far as finding locations go, I suppose you can always activate map pins instead of journal entries.

 

Of course, the goal of a module/campaign author is to make the experience so engaging that no-one will want to stop playing in the first place.

[Eguintir Eligard]

I think I just fell in love with my quest example above. Unfortunately it will spell the end of Grunty the Orc, Stinky the Troll, and Fartsmeller the Imp in the Tournament of crowns campaign 

[Dann-J]

 

 

I will try to give another example.

Typically in the OC or many player campaigns, if you are given the quest below:

 

• You enter Ye Olde Pub (Ye Old Pube?)
• Fatso the Barkeep says: I have made a few enemies. Kill them all. Grunty the Orc, Stinky the Troll and Fartsmeller the Imp. When you are done I need you to also get a shipment of Pies from the local bakery.

 

From what I have seen in return of the exile, I would get a quest journal entry saying to do all of the above. And then I would do it, but the journal doesn't change until I am done the quest entirely, then I go back and tell Fatso the Barkeep all I did and the quest ends. So if you are not using journal entries for each step you must be using variables. That's tricky plus you can not see if they are working without using debug all the time.

 

Rather than use variables, you could have the quest giver demand proof of the deed(s) in the form of body parts, like in NWN when you had to return the ears of escaped prisoners. That way the player always knows who has been killed and who is remaining simply by looking in their inventory.

 

I like to 'curse' and 'plot' such items via an OnAcquire tag-based script to ensure that players can't drop or sell them once collected. Transferring them to the first PC before 'cursing' them might be a good idea too, in case you have other party members pick them up. Otherwise you could dismiss them from the party and they'd take your plot tokens with them. Although a custom dismissal script that checks for plot/cursed items could uncurse, transfer, and re-curse such items (of just CopyItem them to the PC and destroy the original).

 

Then the quest giver's conversation just has to check that the party has all of the required trophies to end the quest.