Sorry. You can only do that once per session.

I wrote a short "between battles" script which tested my mp level and cast a buff on a target.

It performed as expected about 5 times but then it stopped with the following error message
"Sorry. You can only do that once per session."
I am confused.

this is the script in it's entirety.

if ( my_mp() > 100 )
{
cli_execute("cast " + int_to_string(my_mp()/15) + " empathy on mud_bat");
}

Try this.

I think that should work

[quote author=exdeath link=topic=145.msg744#msg744 date=1147223946]
Try this.

I think that shold work
[/quote]

That would only work if they are not trying to buff someone else. They may be trying to buff themselves from a multy.

Oh on a target. Didn't see that. Either way it probably wouldn't work without the

void main(){ script }

Try the original code with that stuff around it.

[quote author=exdeath link=topic=145.msg753#msg753 date=1147292526]
Try the original code with that stuff around it.
[/quote]

Actually, the original would work just fine without the main tag.

It is, however, a good idea to get into the habit of defining a main function in any script.


As for why it stopped working, it might be built in spam protection. To prevent any one person from spamming someone else. Even with buffs.

As an alternative idea, you might check the buffbot settings. There might be a setting that limits the number of buffs sent to one target per session. The default might be around 5. And that might interfear with your buffing.

That's what it was, spam protection written into mafia. The name of the target is added to UnRepeatableCommands.

I was wondering why they would restrict it like that but spam protection makes sense.

Thanks for the input everybody.

[quote author=Presto Ragu link=topic=145.msg756#msg756 date=1147296061]
Actually, the original would work just fine without the main tag.

It is, however, a good idea to get into the habit of defining a main function in any script.[/quote]
Why?

I'm not trying to be dense or snide, but I never bother; if you don't have one, ASH collects all of the "top level" commands into a scope which is the functional equivalent of a "main" function.

In fact, if you "include" a script, I'm not sure how it treats "toplevel" commands. Does it collect them into an implicit "main" which you can never execute, since you can't call it? Does it just add them to the current "top level" commands, so that all such commands from all included files will get executed? (Which won't work if you actually DO have a "main" function in outermost script.)

I suppose if you always define a "main", then ASH will give you an error if you ever include one of your "top level" scripts in another.

But is that it? Is that why you think it's a "good idea" to always define a "main" function?

I'm still not convinced. I'd just as soon have my top-level commands unindented, rather than inside a pseudo-function.

Why?

Consistency, and correctness.

If you have the choice of doing something the "right" way, and the "wrong" way, you are better off getting into the habit of doing it the "right" way.

Functionally there is no difference. A completely off the wall, and incorrect, analogy would be: Since you are capable of submitting a resume hand written, why should I send in a typed resume?

Now, that isn't even the same ball park... But it should be exaggerated enough to get my point across.

Maybe I am just being nitpicky. But then again, I am the kind of person that (almost) always double spaces between sentences - even if the medium I am typing to takes out the second space. :shrug;

[quote author=Presto Ragu link=topic=145.msg778#msg778 date=1147463512]
Why?

Consistency, and correctness.

If you have the choice of doing something the "right" way, and the "wrong" way, you are better off getting into the habit of doing it the "right" way.[/quote]

Let me rephrase my question:

Why do you believe that putting your top-level commands inside a "main" function is the "right" way? What, exactly, is more "correct" about doing that than simply having them at top-level in your script?

Imagine that ASH never provided the ability to place your top-level commands inside a "main" function, and required you to simply have them at top level in the file.

Or, alternatively, imagine that ASH required you to have a "main" function.

In neither case would there be any difference whatever from what you can do in ASH scripts right now. In either scenario, there is one "correct" syntax, enforced by the parser. In current ASH, the parser allows either and prefers neither.

You've made it clear that one way is YOUR "preferred" technique, but I think you're reaching quite a bit to try to justify it on the basis that that is the "correct" way to do it.

I'm tempted to go and DEFINE a (useful) functional difference between "top level commands" and a "main" function...

Alright, how is this:

If you get into the habit of always writing your ASH scripts in a main function (at least), it makes transporting them between people and other scripts much easier.

If you are going to import the script, all you have to do is change the name of the function from main to whatever else you want to call it.

Also, if you go a step further, and always write your scripts into a function, and just make your main call that function, you are already ahead of the game.

Throw in a healthy dash of "old school" programming teachings - I remember the thought that you main function should only contain function calls (and the occasional conditional check) - and you can further understand my point of view.

Now, if your purpose was just to understand why I said what I said, then you should have a pretty damn good idea of my rational.

If you had other motivations, you were too subtle for me to pick them up, and I would recommend a more direct approach.