If i set it to have a $${DO}$$ and not set a number, how do i stop it mid way through?
Depends on how you want to stop it...
If you want to stop on some condition, the example given is pretty good...
If you want to stop if some point (f. ex. an IF statement) is reached you can use the BREAK; command which goes to the end of the nearest FOR, FOREACH, or DO that you are in
alternatively you can also use Stop() to completely stop the running script (and any others spawned from the same key/event)
Finally, you can use Stop(*) from another script to stop all running scripts, or press macro activate to get a list of running processes and stop them one by one from there
Is there a way to get it to click in a GUI/Chest? for example to click the blaze rods
I tried using $${SLOTCLICK(#)}$$ but it only recognizes inventory slot
Thank you
That's.., not true, the slot numbers depend on what GUI is open, and 0-9 shouldn't even be the hotbar, it's usually the topmost slots
In settings you can turn on "Show slot ID's in containers" to find out exactly what number each slot is
So I made a macro that uses precise timings to control the player. However, if the player happens to lag during this time, they stop moving. This messes up the timings a lot. Is there any way to not have my macro affected by client lag?
Never use timing to control something other than timing
If you want to move to a specfic position for example.., check the position, not the time - using XPOS, YPOS, ZPOS
Unfortunately it rounds to the nearest coordinate, and your player has enough width to be in the middle of two, so it might help to sneak when you're about to reach your target or find the module that gives you 1/10'th precision for coordinates
In any case, it's not going to be easy - consider if it might be easier to edit the terrain to suit the script
I tried to do the following script, but it just froze because I accidentally made an infinite loop. Something is wrong with my IF and/or UNTIL commands but I can't tell what. Help please Murphey?
&one = 10
if(%&one% = %@#counter%)
else
do
inc(@#counter)
until(%&one% = %@#counter%)
endif
What if @#counter is larger than 10?
Don't use double-equals unless you absolutely mean it - when you want to do something until you reach a threshold, always use comparisons...
Also, you're comparing a string to an integer, which is also not good
#target = 10;
IF(@#counter < #target);
DO();
Inc(@#counter);
WHILE(@#counter <= #target);
ENDIF;
I'll look at the second part later when i have more time, but do fix your indentation.., quite likely you're just missing an endif or something like that.
key(jump) isn't working for some reason. The only way I can make it trigger the spacebar is keydown(jump)
Oh, my bad, i guess it's a stateful binding (and not a trigger) binding then
In that case most of the above applies, except Key() cannot be used and KeyDown/KeyUp can
This also makes the script slightly slower since pressing and releasing the key on the same tick probably won't work right
$${
KeyDown(jump)
Wait(1t);
KeyUp(jump)
Wait(1t); // If it doesn't work, slowly raise this delay
KeyDown(jump);
Wait(1t);
KeyUp(jump);
}$$
Let me rephrase: How do I make it double tap space bar to fly when I have permission to fly. There is a prison server that I'm trying to automate a minebot and once it hits bedrock I want it to hold down space.
Well, first of all, there's nothing special about the space bar, so let's talk about things as they really are
What you want is not to hit the space bar, what you want is to trigger jump
With that out of the way, since Jump is a trigger binding (as opposed to a stateful one like the movement keys), you can use the Key() command to trigger it
Since we also need at least a tick of non-jump time for it to count as two presses, let's also use a Wait() in between
$${
Key(jump);
Wait(1t); // Raise if necessary, but hopefully one tick is fine
Key(jump);
}$$
Hey, I'm fairly new at this and am wondering how to do something. I'm not sure how to simply display a variable. I'm trying to show what my saturation is and I'm not sure how to do it. As of now I have
$${LOG(SATURATION)$$
Now I know this is wrong, all it will do is send that word "SATURATION" as a log. How would I make it actually show what my saturation is?
If you only want the value of the variable (as opposed to the variable itself), you can wrap it in percent signs to 'expand' it
$${Log(%SATURATION%)}$$
Cases where you don't just want the value are all the commands that actually modify a variable.., hence they need to know what variable you're interested in
So the following is valid
#value = 10;
Inc(#value,2); // increment #value by 2
Log(%#value%); // essentially Log(12)
But this is not
#value = 10;
Inc(#value,2); // essentially Inc(10,2), INC has no way of knowing what variable to save to.., "10" is not a valid variable name
Log(%#value%); // essentially Log(10) since #value is unchanged
Other special cases are IF statements and assignments, where variable names are recognised and their values used
using percent signs to expand values turns numbers into strings, which makes "<, <=, >, and >=" work incorrectly
so IF(#count < 5) is perfectly valid, while IF(%#count% < 5) will sometimes give you the wrong result
probably same for
#a = #count + 5; // Definitely works
vs
#a = %#count% + 5; //Might not work (?), i'm not sure
But in all other cases.., if the command would work with a literal value, use percent signs if you want the value from a variable
Does anyone know how to make a random command executed macro?
For example:
ECHO("/Command 1")
ECHO("/Command 2")
I want to make a macro with 2 commands binded, but when I execute that macro, instead of having both commands executed, I want the macro to pick at random which command to execute for me, so either command 1 (or anything I put in ECHO 1) or command 2 (or anything I put in ECHO 2).
This is mcmmoAcrobatics.txt, and it's having some issues.
I have a beacon with regen, so I just fall a lot.
When my health is 20, I go to "/home farm" and walk forward, get hurt really bad, and just walk into a wall and wait for the beacon to do its job.
The LOG will always tell me that #falls is 1, because I manually set it to be 1. The INC isn't INCing.
As best as I can tell, I am mentioning the variable as a name where it needs to be and as a value elsewhere, so I really have no idea what's wrong.
Also, it calls itself at the end of the function because I couldn't get a DO;LOOP; working right.
This macro is activated by a button on the text-buffer screen.
I have never gotten #falls higher than 1, so I don't know if the second part of the macro works or not.
EDIT: Forgot to mention the SET at the beginning. It's to create the variable because I'm not sure how this mod handles null variables. I SET #falls to 0, and it successfully INCed to 1, so I tried removing SET, no dice. I add SET(#falls,%#falls%) in hopes that such would work, no dice. That's everything I can tell you.
Unset variables act like their default values
booleans are false,
integers are 0,
strings i assume are empty
Of course if you set your variable to 0 and INC it once it's always gonna be 1 and never 9
You probably expected removing the Set() to make it save it's value
Values are saved to the context of a button, keyboard key, or event - whatever the script is bound to
When you exec a file, it starts a new process with no context, and thus nowhere to read variables from or save them to
This is why even without Set() it keeps resetting to 0 and then back to 1
So it's not Inc that wasn't working, it was the variable itself
protip: if you think something is broken, try and eliminate other causes - craft a simple test for it
for example if i thought Inc was broken i'd try and eliminate any other influence by doing the following
Set(#test,0);Inc(#test);Log("%#test% should be 1");
Set(#test,1);Inc(#test);Log("%#test% should be 2");
Set(#test,15);Inc(#test);Inc(#test);Log("%#test% should be 17");
But why are you using Exec at all?, and tail recursion? why not just loop it naturally?
--------
Is this what you meant to do?
Do(); // This part repeats, isntead of recursion let's just mark the loop explicitly
IF(HEALTH == 20); // IF statements are an exception to the "if you're using the value, percent it" rule - number comparisons work better without
Do(9);
Echo(/home farm);
KeyDown(forward);
Wait(5);
DO;nothing;UNTIL(HEALTH == 20); // Wait until full health
ENDIF;
// Whatever this is for...
LOG(You've fallen a lot. Better rest!);
WAIT(900);
Hey, for whatever reason, this macro won't DEC my #variable.
It's bound to a key, and it waits right, but the log keeps spitting out "300, 300, 300, 300" instead of "300, 299, 298, 297".
EDIT: Solved my own problem. Took the %'s off of the DEC command. Works like a charm.
Just to clarify why this happened, when you type %#varname%, you're essentially saying "current value of #varname"
Dec is supposed to decrement a variable, but it needs to know which variable you want decremented, it's expecting (the name of) a variable
With percent signs, you're only giving it the current value, but it doesn't know which variable you want decremented.
When you removed the percent signs, leaving only #varname, you started giving it the name of the variable instead, so it knows what to decrement
Generally, if you can replace a variable with its' literal value (the command is expecting a value), use percent signs.., if it has to be a variable, don't
This is a server-side restriction. Basically the mod limits the message length on purpose because if you send a chat message which is longer than the allowed limit, the server would just kick you. A way to work around this would be to write a server plugin which accepted long messages on a pluginchannel, and then I could provide client-side support for sending those messages in the mod. But basically, if you have no control over the server it's impossible.
Because in order to function, chat filter scripts run synchronously on the network thread. This means that all latent functions such as WAIT are prohibited.
Tested it. Once the original chat message has been FILTER-ed, the onChat script cannot pick up the phrase in chat anymore... Any solutions>
Hmmm..., i guess this is one of those rare cases where an Exec seems like the perfect solution...
Put the rest of your script (including all the Wait'ing) in a separate file and call it with
Exec(filename.txt,"processname",%CHAT%,%CHATCLEAN%)
Then, if i'm not mistaken, you can use $$1 in place of %CHAT% and $$2 in place of %CHATCLEAN% in your script
And since Exec starts a new process it shouldn't block or be limited by the ChatFilter
Tested it. Once the original chat message has been FILTER-ed, the onChat script cannot pick up the phrase in chat anymore... Any solutions>
Hmm..., you mentioned not being able to use WAIT in the chatfilter..., any reason?
Last i recall it works fine, it just delays the message with it (but if you're filtering it out anyway that shouldn't (?) matter)
Well normally the executive is pre-emptive (to allow multiple simultaneous macros to run without burdening the game and will force a script to yield when:
The current script action is executing in "latent" mode (eg. reports to the script engine that it wants to receive ticks until further notice, such as WAIT)
100 ms have elapsed since the last pre-emption
100 actions have been executed
Any stack pop operation is processed
Most often in practice, it's the first and last condition which cause a script to yield. This means they then wait for the next tick (or in the case of latent functions, the next game loop) to continue execution, since a tick is 1/20th of a second this is a long time. This means that:
DO(1000);LOOP
takes a minimum of 50 seconds to execute, since every time LOOP is encountered the execution pointer's position is popped from the stack (to point it back at the DO) and this triggers the pre-emption in the executive.
This is done 100% on purpose to limit the script engine's ability to affect the game's speed. Intensive scripts can still slow the game down by the processing they must undertake, but in general the game keeps going.
The problem with this pre-emption is that it can make some otherwise simple tasks take forever if they use loops or lots of IF's, making loops impractical for some things. What UNSAFE does is remove all of the above pre-emption conditions except for the first one, and allows the third to be tuned. The reason I chose to call the command UNSAFE rather than FAST or NOLIMIT or something is to make scripters think before using it - using UNSAFE you really can crash the game (or at least bring it close to its knees, there's still one final safeguard which can't be circumvented with UNSAFE). Try binding $${UNSAFE(0);DO;LOOP;ENDUNSAFE}$$ to a key and hammering it a bunch of times (hint: don't do this).
The argument passed to UNSAFE is sets the value within the UNSAFE block of the 3rd pre-emption condition, if not supplied it defaults to 100 but UNSAFE(0) disables the check and allows the fastest possible execution. However latent functions will still yield to the game and so WAIT and its latent brethren are still fine.
You can also tune parameters 2 and 3 using the config file, allowing degrees of freedom between full over-zealous pre-emption and UNSAFE's "to hell with the rules" approach, UNSAFE is the only way to disable pre-emption on stack pops however.
0
Depends on how you want to stop it...
If you want to stop on some condition, the example given is pretty good...
If you want to stop if some point (f. ex. an IF statement) is reached you can use the BREAK; command which goes to the end of the nearest FOR, FOREACH, or DO that you are in
alternatively you can also use Stop() to completely stop the running script (and any others spawned from the same key/event)
Finally, you can use Stop(*) from another script to stop all running scripts, or press macro activate to get a list of running processes and stop them one by one from there
0
That's.., not true, the slot numbers depend on what GUI is open, and 0-9 shouldn't even be the hotbar, it's usually the topmost slots
In settings you can turn on "Show slot ID's in containers" to find out exactly what number each slot is
0
"UP" is not a stateful action.., it's not really an action at all
...do you mean "forward"?
0
Never use timing to control something other than timing
If you want to move to a specfic position for example.., check the position, not the time - using XPOS, YPOS, ZPOS
Unfortunately it rounds to the nearest coordinate, and your player has enough width to be in the middle of two, so it might help to sneak when you're about to reach your target or find the module that gives you 1/10'th precision for coordinates
In any case, it's not going to be easy - consider if it might be easier to edit the terrain to suit the script
0
What if @#counter is larger than 10?
Don't use double-equals unless you absolutely mean it - when you want to do something until you reach a threshold, always use comparisons...
Also, you're comparing a string to an integer, which is also not good
#target = 10;
IF(@#counter < #target);
I'll look at the second part later when i have more time, but do fix your indentation.., quite likely you're just missing an endif or something like that.
0
Oh, my bad, i guess it's a stateful binding (and not a trigger) binding then
In that case most of the above applies, except Key() cannot be used and KeyDown/KeyUp can
This also makes the script slightly slower since pressing and releasing the key on the same tick probably won't work right
$${
KeyDown(jump)
Wait(1t);
KeyUp(jump)
Wait(1t); // If it doesn't work, slowly raise this delay
KeyDown(jump);
Wait(1t);
KeyUp(jump);
}$$
0
Well, first of all, there's nothing special about the space bar, so let's talk about things as they really are
What you want is not to hit the space bar, what you want is to trigger jump
With that out of the way, since Jump is a trigger binding (as opposed to a stateful one like the movement keys), you can use the Key() command to trigger it
Since we also need at least a tick of non-jump time for it to count as two presses, let's also use a Wait() in between
$${
Key(jump);
Wait(1t); // Raise if necessary, but hopefully one tick is fine
Key(jump);
}$$
0
If you only want the value of the variable (as opposed to the variable itself), you can wrap it in percent signs to 'expand' it
$${Log(%SATURATION%)}$$
Cases where you don't just want the value are all the commands that actually modify a variable.., hence they need to know what variable you're interested in
So the following is valid
#value = 10;
Inc(#value,2); // increment #value by 2
Log(%#value%); // essentially Log(12)
But this is not
#value = 10;
Inc(#value,2); // essentially Inc(10,2), INC has no way of knowing what variable to save to.., "10" is not a valid variable name
Log(%#value%); // essentially Log(10) since #value is unchanged
Other special cases are IF statements and assignments, where variable names are recognised and their values used
using percent signs to expand values turns numbers into strings, which makes "<, <=, >, and >=" work incorrectly
so IF(#count < 5) is perfectly valid, while IF(%#count% < 5) will sometimes give you the wrong result
probably same for
#a = #count + 5; // Definitely works
vs
#a = %#count% + 5; //Might not work (?), i'm not sure
But in all other cases.., if the command would work with a literal value, use percent signs if you want the value from a variable
0
it?
If you mean yourself.., you can't
It's a scripting language, not a cheat engine
2
RANDOM(<#target>,[max],[min])
For example
${
RANDOM(#which,1,5);
IF(#i == 1);Log("one");ENDIF;
IF(#i == 2);Log("two");ENDIF;
IF(#i == 3);Log("three");ENDIF;
IF(#i == 4);Log("four");ENDIF;
IF(#i == 5);Log("five");ENDIF;
}$
Or, if your specific goal is to log a random message.., let's randomize only the message instead of the entire script
${
// Prepare messages (technically this only needs to run once)
UnSet(&messages[])
&messages[] = "one";
&messages[] = "two";
&messages[] = "three";
&messages[] = "four";
&messages[] = "five";
// Pick a random index and log it
RANDOM(#index,0,4);
Log("%&messages[%#index%]%");
}$
0
Unset variables act like their default values
booleans are false,
integers are 0,
strings i assume are empty
Of course if you set your variable to 0 and INC it once it's always gonna be 1 and never 9
You probably expected removing the Set() to make it save it's value
Values are saved to the context of a button, keyboard key, or event - whatever the script is bound to
When you exec a file, it starts a new process with no context, and thus nowhere to read variables from or save them to
This is why even without Set() it keeps resetting to 0 and then back to 1
So it's not Inc that wasn't working, it was the variable itself
protip: if you think something is broken, try and eliminate other causes - craft a simple test for it
for example if i thought Inc was broken i'd try and eliminate any other influence by doing the following
Set(#test,0);Inc(#test);Log("%#test% should be 1");
Set(#test,1);Inc(#test);Log("%#test% should be 2");
Set(#test,15);Inc(#test);Inc(#test);Log("%#test% should be 17");
But why are you using Exec at all?, and tail recursion? why not just loop it naturally?
--------
Is this what you meant to do?
Do(); // This part repeats, isntead of recursion let's just mark the loop explicitly
Do(9);
KeyDown(forward);
Wait(5);
LOG(You've fallen a lot. Better rest!);
WAIT(900);
ENDIF;
Loop;
1
Just to clarify why this happened, when you type %#varname%, you're essentially saying "current value of #varname"
Dec is supposed to decrement a variable, but it needs to know which variable you want decremented, it's expecting (the name of) a variable
With percent signs, you're only giving it the current value, but it doesn't know which variable you want decremented.
When you removed the percent signs, leaving only #varname, you started giving it the name of the variable instead, so it knows what to decrement
Generally, if you can replace a variable with its' literal value (the command is expecting a value), use percent signs.., if it has to be a variable, don't
0
Hmmm..., i guess this is one of those rare cases where an Exec seems like the perfect solution...
Put the rest of your script (including all the Wait'ing) in a separate file and call it with
Exec(filename.txt,"processname",%CHAT%,%CHATCLEAN%)
Then, if i'm not mistaken, you can use $$1 in place of %CHAT% and $$2 in place of %CHATCLEAN% in your script
And since Exec starts a new process it shouldn't block or be limited by the ChatFilter
0
Hmm..., you mentioned not being able to use WAIT in the chatfilter..., any reason?
Last i recall it works fine, it just delays the message with it (but if you're filtering it out anyway that shouldn't (?) matter)
0