Post: #7

1. ARGS allows the use of strings... maybe use ARGN to force only numbers. Either that or validate that only numbers were entered.

2. There are limits to the biggest number you can store in MORE1 and MORE2 ... your deposit and withdraw functions need to accomodate those limits. Also, the limits for MOREX and MOREY are a potential problem as well.

3. Your script is not properly testing for negative numbers (what happens when someone deposits -50000 or withdraws -50000)... This is due to bad logic (too many IFs and not enough ENDIFs and/or they are in the wrong order. My suggestion is put all the failure conditions in their own IF/ENDIF section at the top of your function.

4. As a general rule, SRC.NEWITEM is bad form, always use SERV.NEWITEM or run the risk of an invalid reference.

5. SRC.ACT.anything makes no sense... by doing this you are chaining references and run the risk of invalid objects breaking your command. Also, it is possible to exploit scripts that rely on SRC.ACT to modify other objects... for example, I could exploit your script to give myself a +50 magic sword... or I could exploit it by emptying the bank of someone standing next to me!

6. Be careful with things like this: IF <ARGS>+<SRC.ACT.MORE> ...because if <ARGS> is a string (which I mentioned earlier is possible) you are literally putting a plus sign at the end of it followed by the value of <SRC.ACT.MORE> (which, because its exploitable, might come from my new magic sword's MORE value... not your bank memory object.) The solution is to force it to be mathamatically considered by putting the condition in () marks or <EVAL >

7. There is no need to add negative numbers like this: SRC.ACT.MORE=<SRC.ACT.MORE>+-<ARGS> ... just subtract directly like this: SRC.MORE -= <ARGN>

8. Don't overload ACT... it is there for built-in actions of the core system... instead, do this: REF1=<findid(i_bank_mem).uid>

9. Deposit does not have a trailing e

:-)