Have a NPC check for multiple items?

[Legacy_KMdS!]

               

Hmmm. As long as you set up the proper protocols for dealing with the stored variables, reseting at appropriate locations in the conversation etc., how can it be exploited?

 

Simple conversations my not encounter a problem, but it's best to know the possibilities.

 

My main concern is running loops in inventory, given there are 300 open slots for inventory which players load up with containers allowing for an additional 35 slots each, it can cause a problem. Even though many inventory items take up up to 6 slots, players can easily accumulate 3 to 4 hundred items or more. The nw engine has a hard coded limit of 1000 instructions, any second or third inventory loop can exceed the limit and break the running of the code and pay havoc with convo conditionals. Since the item searche methods all run an entire inventory loop the situation can come up.

 

Best to plan your use of loops. The best option is to plan ahead and the submitted code is a starting template.

 

Please let me know if you have information I am missing Lightfoot8, you are one I know that knows your stuff.

 

Thanks.

               
               

               
            

[Legacy_Lightfoot8]

               

The exploit happens when the PC starts dropping / handing off items mid conversation.   So since you need to double check or reset your count anyway why not just recount them every time.  An exception would be if you need the same count in  several starting conditions on the same node, where the PC does not have any response time.  

 

As far as hitting the TMI error.   that is only going to happen if you over load a single script.  Running a script from a script without delay would also keep the instruction count progressing.    But from the conversation the instruction count will get reset at the beginning of every script ran.  So every starting condition/ action taken script has its own instruction count and it does not matter what happened in the other scripts.   

 

As far as number of executed VM  Instructions it takes to get a TMI the number is 0x2000 in hex. Or 8192 in decimal.  

Hmm that number still seems small. I my have to double check my memory later.     

               
               

               
            

[Legacy_meaglyn]

               

Saving the actual object,  not just the count, as KMds! is doing should mitigate the dropping/handing off issues. The items could still be destroyed or taken.  Edit: but that still can be exploited for stackable items...

 

The instruction limit is 0x20000 (131,027). I think you dropped a 0 '>

               
               

               
            

[Legacy_KMdS!]

               

That is a very good point LF8. Hmmm...There are ways to prohibit that through proper code logic, and the example code allows for it, possibly even can handle it better that any other way. Since the number of instances are stored, not the number it items, you can perform a small loop through the just saved objects to verify the item count as a check. No matter what the pc does, short of destroying the item during the specific node chain, the item would be processed. Making proper use of the conditional, action taken and end events there should be no escaping or exploit. Logic can prevail, as long as you know what your up against.

 

There will always be those that want to exploit the system and no method is immune, all we can do is plan for all we can conceive and get our friend to help us try to cover all the bases. Thanks, that particular exploit had not occurred to me.