Minecraft Forums

Quote from zeel

Thanks for the updates, very helpful.

Some questions. . .

When I parse the servers reply to my /money command (BTW it was the %CHAT% I didn't know I could use) I can isolate the number. However when I submit it to the server it gets unhappy because the number contains commas and a decimal but it wants an integer. I have tried looking for help using RegEx to no avail. How can I remove the commas?

Hmm, I haven't tried it but you could try assigning the captured string to a counter variable, this would essentially call Integer.parseInt() on the value and may ignore the commas, or it may choke on it and just assign zero. Give it a try.

Quote from zeel

And I was wondering, are you planing on implementing math functions (+ - * / operators)? And use varName = value instead of SET();? Would be great if I could do something like donate only 75% of my money to my town. Turring completeness is nice. . .

Mathematical operators are on the roadmap for the version after 0.9. My focus at the moment is on the newer trigger mechanisms for macros, in particular bringing events up to where I want them functionality-wise and adding the custom GUI functions for the macro playback screen. These are the key features I've slated for 0.9 and are the current thrust of development. The reason events seem a bit rough around the edges and unloved is that as it exists in 0.8.5 it's really just a general testbed for the events, 0.9 will make them seem more like a first-order feature in the mod.

Quote from zeel

I noticed that the text boxes you use are not the same as the rest of MC, they have always been better. Until now, with 1.2.4 they lack some of the functionality. Are you planing on implementing something more like the chat GUI (with copy and paste support)?

There are actually 2 types of text box in the mod, GuiTextFieldEx which just added scrolling support and will be phased out in favour of the new text boxes, and also GuiTextFieldMacroEdit, which is a little more involved and supports syntax highlighting which I will merge some of the newer textbox functionality into, it's a little too complicated to throw away completely because the syntax highlighting is a bit of a nightmare.

Quote from zeel

While working with the RegEx I noticed that any time I made a syntax error Minecraft will crash. It would be nice if macro mod would catch the error and prevent the total crash.

Should now catch this in 0.8.3, the catch clause in that class wasn't quite as wide as it should have been!

Quote from zeel

BTW, the fishing script was derived from a YouTube video.
It does not work in 1.2.4 as the video describes it. And it does edit default classes. However I hope this info at least gives you some idea of how to proceed.

I'll check it out, it's definitely something I'm considering but I have to try to prioritise what features to add.

Quote from zeel

EDIT: I would be very interested to see the source, and the readme.txt said to ask in this thread.

I'll pm you a link to the current source.

Quote from Wouterhehe

Let me start by saying you have done an awesome job with this mod Mumfrey! Really like it!

I do have a question though. I was trying to setup a menu like command for all the different /warp /homes /tp /msg features on my server. /snip

Hi, sorry for the super-slow reply but I kind of got side-tracked by the whole password theft fiasco and I wanted to answer this one in full.

Ok this probably requires some explaining, it is possible to achieve what you want, but it needs some background information.

Parameters in macros are not dynamic, they are not part of the macro's execution but are instead hints to the macro compiler that it needs to "fill in" some information before the macro is run. When you create a macro what you actually create is a Template, and this is what the macro parser compiles when you trigger the macro.

In a simple example, you might have the following template:

/give Mumfrey $$? 64

It's pretty clear what this macro does and when it's invoked the macro parser sees the $$? parameter and prompts you for the value. If you enter 322 at the prompt, the macro parser replaces the value you type in and then essentially begins again, checking for parameters. Only when there are no more parameters will the macro actually be sent for execution.

So with our example, the final "compiled" macro is a single chat message action which contains the compiled text:

Chat Message=[/give Mumfrey 322 64]

Only templates which are triggered by key events can prompt for parameters, event templates and spun-off templates cannot prompt for parameters, although spun-off templates can accept parameters passed in with the originating EXEC command. The reason for this is that there's no way to tell when these type of macros may be triggered, and having them pop up asking for input at random times would be disruptive.

There is one type of parameter which is always processed however, and that is the file include parameter, written as $$<filename.txt>. This type of parameter is always processed first and is processed even in macros which can't prompt the user for parameters. Let's assume we have a file containing the following script:

file.txt

/give Mumfrey $$? 64
/gamemode Mumfrey 0

Next we write a macro with the following code and bind it to a key:

Foo bar baz|$$<file.txt>

When this macro is executed, the compiler first looks for parameters in the macro that need replacing. Since file includes have the highest priority they get processed first. This means the macro looks like this after the first step:

Foo bar baz|/give Mumfrey $$? 64|/gamemode Mumfrey 0

Notice that the include changes line breaks in the file into pipe characters as you'd expect. At this point there's still a parameter in the macro however, so the compiler loops back to the start and checks again for parameters. This time it finds the $$? parameter and prompts the user for input, the user enters 46 at the prompt.

This means the final macro consists of 3 actions:

Chat Message=[Foo bar baz]
Chat Message=[/give Mumfrey 46 64]
Chat Message=[/gamemode Mumfrey 0]

As you can see, the final macro which is executed has all of the parameters "filled in", and the macro which is actually executed is just the final, compiled chat commands as 3 separate actions to execute.

Let's look at an example with scripts. Imagine you have the following script in a file:

script.txt

IF(~CTRL);
   ECHO("/gamemode $$u 1");
ELSE;
   ECHO("/gamemode $$u 0");
ENDIF;
WAIT(2);

Like before, we can bind the file to a key using an include parameter. In this case we need to remember to put script delimiters around the include so that the included file will be treated as a script, but this happens later than you might imagine.

$${$$<script.txt>}$$

after the file is included becomes:

$${IF(~CTRL);|   ECHO("/gamemode $$u 1");|ELSE;|   ECHO("/gamemode $$u 0");|ENDIF;|WAIT(2);}$$

There are still parameters though so the user is prompted for the value:

$${IF(~CTRL);|   ECHO("/gamemode Mumfrey 1");|ELSE;|   ECHO("/gamemode Mumfrey 0");|ENDIF;|WAIT(2);}$$

Now the macro is fully compiled (there are no more parameters to parse), so we end up with:

IF action=   [Check whether ~CTRL is true]
ECHO action= [/gamemode Mumfrey 1]
ELSE action= []
ECHO action= [/gamemode Mumfrey 0]
ENDIF action=[]
WAIT action= [wait 2 seconds]

Notice that while the parameters are fully resolved before the macro is executed, the variable ~CTRL is not, this is the key difference between parameters and variables. Parameters are replaced during compilation to "build" the macro, and variables are evaluated while the macro is running. It should be clear by now that until the macro is fully compiled, it has no idea whether a parameter is going to be needed or not because the early part of the compiler that replaces the parameters is not even aware that the script is a script.

You can however harness the recursive nature of the early compiler to achieve what you want:

Consider the following simple macro:

/give Mumfrey $$?

When this macro is triggered, the user is prompted for an input. The user enters "$$i $$[amount]" which makes the macro

/give Mumfrey $$i $$[amount]

The user is now prompted for an item and amount, even though those parameters didn't exist at the start. This is because the compiler is recursive, and after a parameter is entered it goes "back to the start" and looks for more parameters!

You can also do this cunningness with file includes, let's assume we have 2 script files:

warps.txt

/warp $$w

homes.txt

/hg $$h

and our macro like this:

$$<$$[Option[warps,homes]].txt>

The first valid parameter found by the parser will be the list (even though file includes are processed first it won't include a file called "$$[Option[warps,homes]].txt" because it's not a valid file name in the mod's filter. So let's say you choose "warps" from the list:

$$<warps.txt>

Holy crap it's a valid file include! So what do we get?

/warp $$w

Finally there's a valid warp prompt, so the user is prompted for the warp to use and chooses the "TownCentre" warp, there are no more parameters so we are left with

Chat Message=[/warp TownCentre]

So why use EXEC if you can just do stuff with includes?

Well includes allow you include a lot more in a macro than would be possible with only 1 line, including the content to fill out a macro with more complex behaviour and in most cases this is what you should use. However what they don't allow you to do is "spin off" tasks which run independently of the original macro, for example if you want to run multiple background tasks then EXEC is your man. The limitation with EXEC is that it essentially builds a temporary template, known as a "spun off" template. The following EXEC builds a spun off template like this:

EXEC("script.txt")

$${$$<script.txt>}$$

But because the template is spun off, it cannot collect parameters from the user.

My plan is to add a script function to bring up the prompt at a later date, so that you can for example do PROMPTFOR("town",&townvar) and have the result stored in a variable (rather than a parameter), this will allow you to do some funky stuff including putting the prompts inside IF clauses. However I need to separate the GUI code from the compiler a little bit more before this is possible, so it's a ways away yet.

Hope this helps, the reason for the rather in-depth response is I hope it may help other readers get an idea about parameters and the macro compilation process too.

EDIT: It seems I've derped in 0.8.6 when adding lists and they don't trigger recompilation like they should, I'll release a fix when I am able. For now if you use a preset parameter inside the file include with your list of choices in the preset list then it should work:

$$<$$0.txt>

Quote from DrEngine

I should say once more its great amazing incredible mod !!!

Mumfrey
- can you add player variable "direction" ? Current direction of player look - N, S, E, W. Used as a parameter for some command line commands.

Yes I can add this.

Quote from DrEngine

- can I construct command/macro with recursive content ? Example: I need write down command like this "/shop create <shopname> <shoppedItemId>[,<shoppedItemId>][,<shoppedItemId>] ...etc...". I can make macro "/shop create $$[Shopname] $$i,$$i,$$i" but the $$i parameter wil be asked only once and selected itemId replace all occurences of $$i. Can be the same parameter asked more times ? And if I don't enter it the recursive part of macro will end ???

EDIT:
I have read your previous post and my second question could be probably solved by recursive method: instead of $$i,$$i... I'll use $$5 (predefined list). The will include "$$i $$5" and "$$i". As long as I choose "$$i $$5" I can repetedly add more and more item parameters. As I choose "$$i" the macro compilation ends. Is it right ?

Correct, you seem to have answered your own question

Quote from IARI

Thanks a lot for the little module, ive just tested it, works wonderfully.
I can't thank you enough for your incredibly quick replies and admire your apparent dedication.

If you don't mind, id be interested in the mod code, id be happy if you pmed me that link too
Also the complete class code for the little module, so i have a template for my own plugins.

See your PM's.

Quote from IARI

I have one little problem:
As I mentioned before, im using xdotools with this SHELL command now to complement the functionality. in particular, im moving items out of furnaces, chests, brewingstands with xdotools. unfortunately the keybord-part of xdotools does not work in minecraft, i can only move the mouse and emulate clicks (maybe of course im just too stupid).
However, id like to be able to shift-click, so the minecraft client will be responsible for the placement of items. xdotools doesnt let me, i tried things like

KEYDOWN("LSHIFT");
WAIT(100ms);
SHELL("/home/.../BrewEmpty.sh");
WAIT(100ms);
KEYUP("LSHIFT");

which do not work. Is there a way to make this dirty workaround work, or is the "layer of emulation" - if thats a fitting term - not low enough?

KEYUP, KEYDOWN, KEY and TOGGLEKEY are "high level" and work with the minecraft Keybind class. However there are two functions in the mod which are so low that they're positively dirty. These are the PRESS and TYPE commands, these functions inject raw events into the keyboard buffer between when LWJGL polls the input devices and them being read by any other part of the game, these fake events need to be injected every tick if you want to simulate holding down a key.

The approximate order of processing is something like this:

• Minecraft calls Display.update() at the END of its tick
• Display.update() causes LWJGL to poll the OS's input event queue and maps these events into its internal buffers
• Minecraft starts a new tick
• Macros mod deconstructs the LWJGL buffer using reflection and adds and removes key events as needed
• Minecraft runs through its normal tick process using the manipulated buffer

Since I imagine that xdotools is actually injecting events into the OS buffer, you should still be able to harness the buffer manipulation functionality, but you need to inject the SHIFT key each tick for as long as you need, so for 4 ticks use

DO(4);PRESS(LSHIFT);LOOP

instead of the second WAIT command.

Quote from IARI

Or alternatively, is there any wisdom you have for me, so i wont have to do things as dirty as that? ^^

Well I don't know what brewempty.sh does, but if you're ok with shell scripting then I imagine java's not much of a challenge, I've sent you a copy of the current API via PM so you may be able to achieve what you want through that means.

Quote from Nitephyre

Hmm, is anyone else having an issue now with MOUSE3 & MOUSE4 activating the game menu screen when pressed? It only seems to happen when not in fullscreen.

This comes up a lot, it's a bug with certain java/lwjgl versions

Quote from Mumfrey

Indeed, you won't see any problems with the middle mouse because that's accessed through lwjgl. The reason most mods and Minecraft itself can't access those buttons is because LWJGL doesn't provide access to them. The method I use is to query them using jinput (which is a dependency of lwjgl so is available as a library without having to force people to download extra native libraries).

Unfortunately on some operating systems/configurations windows still grabs those events and causes the window to become defocused like you're experiencing, this in turn causes the game to pause and bring up the menu, this isn't just with Java 7 but also Java 6 on some operating systems. The key point is that it's not a bug in the game or in the mod, but something native in the way the window is capturing the mouse that causes the window to lose focus when the mouse3/4 buttons are pressed.

At the current time I really don't have an answer as to why this happens, putting the game in fullscreen always fixes the issue, and others have had success by starting minecraft then clicking off the window and back onto the window, so it may be that this works for you. Java 7 is still in beta so it may be that the final release will fix this issue but somehow I doubt it. Sorry I can't really solve this for you, but further experimentation may help.