What happens if you acquire and drop the same item six times?
Edit: Actually, I see a var check for individual items in the script so that should be fine.
Lance
Ok, I’ll test that with kevL_s original version of the script before going to bed.
I just looked over the script and it does have an individual item check, so should be fine.
Sleep well … Me bed too now💤
Tested, and as expected you can cheat and drop the item and pick it up 6 times and then there will be a journal entry.
Actually, that did surprise me as it looked like there was a var check in place … Oh well, good job you double checked. 
Ok I just looked again and noticed the mark item done is in the wrong place. It needs to be on each item and not just the last one.
Well, for me that was expected since kevL_s already said that that would happen with his first version. Sadly something is wrong with the second version since when I tested that there was no journal entry at all after picking up 6 items.
If I get time tomorrow and nobody has beaten me to it, I will put a version of the sort of script based on an item count.
Basically, if there are only six possible acquisitions, then you can just cycle a loop for every rendition of the item, checking for PC possession. If the count is six, update the journal … But consider what you may want to do if the player drops one again … Do we revert the journal for no longer having enough?
You could always check out some of my code in The Scroll to see what I did there if you want.
Anyway, until later, take care, Lance
Acquire scripts don’t work well with items that stack.
If your boar item has a MaximumStackSize of more than one, then get rid of that blueprint and use some other blueprint that has a MaximumStackSize of 1. Just change its icon, tag, name and whatnot to what you need. Books or rings might be a good base item.
Then use this script:
// 'i_boarh_it_aq'
#include "ginc_item_script"
void main()
{
object oItem = GetModuleItemAcquired();
object oPC = GetFirstPC();
if (IsItemMarkedAsDone(oItem, SCRIPT_MODULE_ON_ACQUIRE_ITEM)) return;
if (IsItemAcquiredByPartyMember() && GetJournalEntry("q_boars", oPC) < 11)
{
int i = GetGlobalInt("nBoarItemsCollected") + 1;
SetGlobalInt("nBoarItemsCollected", i);
MarkItemAsDone(oItem, SCRIPT_MODULE_ON_ACQUIRE_ITEM);
if (i == 6) AddJournalQuestEntry("q_boars", 11, oPC);
}
}
2 Likes
the mistake in my second script is this
object oIt = GetModuleItemAcquiredBy();
should be
object oIt = GetModuleItemAcquired();
sorry, andgalf
2 Likes
My boar item has a MaximumStackSize of 1, so no worries there.
Ah, I see. Thanks for checking out and finding that.
Well, I’ll see which one of your scripts I’ll be using. I’m trying to look at the code and see which one I can follow the best, if I need something similar in the future…I think I might go for travus’ version, even if I can follow both of your codes, I think that travus’ is a bit more compact, and I like the function IsItemAcquiredByPartyMember, so with using his, I might remember this function in the future.
Both of you, thank you so much for all the help! I’ll test this now, and hopefully all works as it should now.
Edit: Tested travus’ version and everything works now!
1 Like
Good to see this sorted.
I was going to mention stack items too, but I see yours do not stack.
One last consideration … If the player pc picks up an item, the way it currently works, they do not need to keep it in their inventory for the journal update to work. I.e. The pc can drop it after picking it up, and the count will still have registered.
So, as long as you do not need the pc to have kept the items to deliver (or use somewhere else), then that is ok. Otherwise, if the player does immediately drop them again, then the logical flow may appear off.
Thanks, Lance
Thanks, I’ll take that into consideration.
Actually, I do need all these items for the PC to deliver, but the way I solved it was to check, in a conversation, for both the journal entry and also run the gc_item_count (which includes code I could have implemented in the other script if that had been needed. The GetNumItems function I didn’t know about, so I’ll try and remember that one).
I’ve got to say, now that I’m working on my fourth module (which may or may not ever be released depending on how it turns out, my third module being beta tested by 4760 and bradcom at the moment), things go so much quicker, since I’ve learned a lot from making the other ones. I know now in many cases what scripts tend to work and how to do things properly. At least I think so. Everything feels a lot more stable.
Hi andgalf,
As you say, experience goes a long way … although, sometimes, it can be a burden when you also learn quite distinctly how easily a piece of code, logical flow or plot can can be upset by a player doing something you did not intend them to do. I find that at least 50% of my code is to cater for the unexpected actions of players. I hope now, however, I have much of the core “checking” code and functions in place and available to reduce this possibility of a break.
A simple tip: When you do something to make your code work and change a variable and or state, double check to see if anything the player does will then change the variable compared to what state you expect them to be in - this especially includes items carried associated with journal states and variables.
This is why I ended up doing quite a few onAcquired and OnUnacquired checks within my own to help keep track of things - Then I realised how much more difficult it became when considering a MP game or even if the player decided to drop a companion that happened to be carrying a “plot” item that was required later on. That last point may apply to your situation too … i.e. What happens if a companion picks up the required item and the player then chooses to leave the companion behind (if that is possible in your campaign)?
However, if you are checking counts within the conversations, you should be good … Just make sure it checks all PCs and not just the speaker - in case the items have been spread about the party. (I think that function you mention may check all, but double check.)
There are a couple of other ways I also consider this …
A) Consider making a single object that represents multiple objects - I did this for collected formulae pages. It involves name change of the item and setting a variable on it.
B) Keep it all in the journal and avoid items altogether - use sparingly as it could spoil the overall “real” feel to the game. i.e. I prefer to ensure the item(s) is/are carried rather than assume it in a journal without any actual item.
Anyway, it’s all food for thought - but it can also interfere with overall production, so handle info with care.
Thanks, Lance.
I believe the gc_item_count checks for all the companions and the player last I checked. Actually, I quite sure, since I remember the last time I tested this quest I had a couple of the items on the PC and a couple on a companion, and it still worked.
Yeah, just having the journal say you have an item could be dangerous since the player can feel like dropping the item.
I concur!