Simple Safe
 

Intended for a class. Just a quick one I threw together, and some player wanted it. So... Here it is :)

Feel free to point out mistakes.

Consecutive if statements without using else if is improper programming. Although it works fine in GScript, if you tried programming like that in other languages, the compiler would report errors.

Also, to help prevent possible glitching, you should take the absolute value of the donated amount and then run your checks from there. I see that you do have a > 0 check, but you don't have any else statements in the code which makes it not-so user friendly when it comes to the script reporting proper syntax for players that use the donate command improperly.

For the withdraw bit, you should create an array where you can simply add accounts to the array granting permission to withdrawing from the safe. For convenience, adding and removing of accounts into the array should be able to be handled from client to prevent the inconvenience of loading the script and editing it each time you wish to give or take the right to withdraw from the safe from someone.

For the actual donating, there should be a verifying option that tells the user how much they are going to donate and asks them if they wish to donate that amount. This is to prevent people from donating an amount that they didn't want to. Perhaps you should also do the same for the withdrawing bit to prevent someone from withdrawing too much or so.

And there should also be a cooldown system for withdrawing to prevent someone from glitching it to where they take money from the chest without the chest actually losing money. The same should be done for donating to prevent adding money to the chest while not removing the money from the player.


Just some things I noticed at a quick glance.

Probably also using int() so people don't deposit/withdraw fractions of currency.

Thanks Gambet. Last time I did the cool down system, I had to change it to clientside for some odd reason. Which enabled more glitching. Or memory editing for that matter. I'll update it in a second.

You should be using the && (AND) operator to join conditional statements rather than having a repeated nested if statement without an else.
Consecutive nested if statements are to be avoided without a good reason (can't think of one).

I should, but this way, I can do what Gambet said (else commands) and make it a lot easier.

You don't need to set any types of flags on the player to give them rights to withdraw, especially a clientr. flag.

Currently, the way you have it, if you have clientr.canWithdraw, then you'll be allowed to withdraw from ANY chest, which is a very bad thing.

Record the string of accounts in the script itself and read it via lindexof or (player.account in array)

That's news to me.

MSVC doesn't report errors for that, or warnings.

By errors I mean errors in result.


Compared to:


I can see where the confusion came from, I should have chosen my words more carefully. My apologies for that, but just know that I'm referring to errors in calculations produced by the compiler, not errors that would keep the code from compiling (of which would yield warnings).

When I think about it, I've never tried the above code in GScript, so I have no clue what results would be produced with the GScript compiler so it might work the same, in which case the first bit of the statement that I made would be false. Regardless, the rest holds its value. Whether GScript bypasses your need to use an else statement in the situation or not, you should always use else if when writing statements checking for different values of the same variable.


Well, combining all of your checks into one statement limits how specific the information that you return to the user can be. If you nest if statements, then you can add an else check to each if statement returning error messages to the user that specifies exactly what they did wrong, rather than a general message coming from a large check that tells the compiler that the user violated one of the checks in the statement.

In the case of the safe script in the first post, if devilsknite un-nests his if statements as you told him to, then he can't report error messages back to the player if they, say, try to withdraw money from the safe but are not in the array of allowed accounts, since every check would be in one if statement and if you violate any of the checks, then the same message would be sent back to the player regardless of which one you violated. In this case, nested if statements would be better in that you can communicate information back to the player more efficiently in the event that they violate separate parts of the checks.

Pseudocode (for the withdrawing bit):

Just an example of why you would nest if statements.

GScript lets a lot of things slide (to my annoyance) but that is certainly not one of them.

I'm quite familiar with the advantages of nested if statements. My case only applies if there is no else or leading or following statements around the nested if statement.

I'm not the only one that should have better worded their original statements. >_<



:)

:p

My initial post is referring to nested if statements that don't have an else or other intermediate statement. Like seen in the OP's original script.

And I am available if you need someone to talk to about programming. :p I will attempt to convince you to learn C++ and Python :)

Although it makes no difference whatsoever during runtime, this just causes obfuscation and should be AVOIDED.

edit: please review.

That is implied. :rolleyes:

Another thing that causes obfuscation would be the lack of spaces between operators, it looks like that was just done so he could better make his point.

Um, what? There is nothing wrong with consecutive if statements if the situation calls for it. It should never error, unless you are referring to a lack of end if/end/fi/whatever (which is a minority of languages)

This is valid php code that is necessary to use two consecutive ifs to do what it needs to do (granted it is pointless)
Um, why? Absolute value? He should just give an error message for anything less then 0 and that is it.

Your case is still wrong (as PFA already pointed out). You don't need an else to justify nested if statements. You should nest if statements if they don't follow the same logical flow. It makes no difference to the compiler so why not make it more readable?

I elaborated on what I meant and gave examples using Java in the previous page. No point on reiterating my explanation, I'm just going to assume that you didn't look at it?

It's a mode of preference, so there shouldn't be an argument because both ways could work without tampering efficiency. Without the absolute value, the script would reject negative values, so if you simply converted the negative values to positive values, then you'd save yourself having to check for only positive numbers.

If the script prompted the user to verify the amount that they are donating/withdrawing, then this wouldn't be a problem, since they could simply reject to donate/withdraw the amount if they entered, say, -5, and the script read it as 5.

Since there should be a verification bit, it would save you a check in the end since you wouldn't have to do if (whatever >= 0), since whatever will always be greater than or equal to 0.


In the end, it depends on how you want to do it.

I would not use absolute value myself. If the person enters -5 they should be told they're not doing it correctly.
I believe I clarified that with consecutive nested if statements.
I already said that was implied. Separating unrelated conditions is not something I think about because I just do it naturally.