Bukkit

Would this work to copy a list fom a permanent object to an object to work with?
'@ADDLIST @Object2.List @Object1.List'

@KyadCK

Interesting. Thanks for your response. My script is working quite well with the use of <getblocklos:LOC:5> but it requires a serious precission to make sure that you are not shooting through the airspace of an adjacent block that has another sign in it. Otherwise, it could alter the wrong sign.

Is there any possibility of, any time soon, geting <triggerloc> working with Click Triggers in ver. 1.3.3.1? Right now, it reports the player's location instead of the location of the trigger block. I am working on a suite of scripts that deals with commerce signs and I am having to use <getblocklos:LOC:5> in stead. The problem with using this is that it returns the location of the first block in the line of sight and not necessarily that of the block your crosshairs are looking on.

@Lyoko_Firelyte

Very good. Looking forward to V2.

@Lyoko_Firelyte

I ended up rewriting the script with a ladder of nested @IF statements and it works fine now.
Yes. If everything that returned a string was error-trapped to return a null string in the event the function breaks, there should be no more need to send these error messages to the console and everything should just work.

This is not a big deal but when you get around to cleaning things up, could you fix '@IF s XXXX = null' to work with placeholders also?
If I try '@IF s <cmdline> != null' I get the error, argument 3 must be a [=|!=|>|<|<=|>=|?=].
I load the <cmdline> into a variable and use it and it works but it still throws an error,
"worng number of arguements" to the console when the command line is empty.

Another problem:
I wrote a script today that uses a @SWITCH statement nested inside an @IF statement. The @SWITCH works properly but the @IF condition always performs as if it were unconditionally true. When I remove the @SWITCH, from @SWITCH to the @ENDSWITCH, the @IF statement works as it should.

My @IF wrapper around the @SWITCH is to emulate a @DEFAULT at the end of the switch. It would be wonderful if you could add a @DEFAULT statement to the @SWITCH. This would save from having to use an @IF statement and a half a dozen or so @OR lines before the @SWITCH. (Even if it did work nested like this.)

I have a problem with my scripts trying to deal with integers and command arguements. The player can enter a string, an integer, or nothing as an arguement. I try to test the arguement first with '@IF i <cmdarg:2> > 0' but get a VT error about not being able to test a string as an integer. If I try to set an integer variable with the arguement and it isn't an integer, I get the VT error "You must only use numbers for [INTVALUE]". Would it be possible to instead of throwing the error to the console, that when the error is trapped, a Zero is returned instead so that the script continues to work?

@Lyoko_Firelyte Excellent! That would be perfect.
I have kinda found the same strategy by just setting up a right click event trigger to only register the RightClick event in a variable like your <clicktype> and then use a normal click trigger to start the script.

It's to bad that I have to abandon the use of <signtext::>. It's useless since it doesn't work with a placeholder or variable for coordinates. This would be such a heavily used enhancement if one could.

What about the dualclick bug I mention some posts below. Could you add a quick hotfix to it? It's really annoying.

Thank you for your effort!

I have a sign on a wall and am using a ClickTrigger to read it. I am using <signtext:<triggerloc>:1> for this and <triggerloc> is rendering the player's position in stead of the position of the sign. Anyone have any ideas?

Also Is there any way to get <signtext::> to work with a variable coordinate?

@Lyoko_Firelyte

When you port to Sponge please be aware of the importance of Vault. Economy and permissions pass through it. Without Vault, most of my scripts will be rendered useless.