Bukkit

Question about<cmdarg:1> returns a null text if it doesn't exist. Is this the word "null" or a string of zero length that is termed to be a null string?

@Lyoko_Firelyte

Because I need it automated. The way I handle the UUID's is by just keeping the Object vars like I always had them ($<playername>:var) and I also have an Object uid.<playeruuid>, which stores the name of that playuuid. I then have added a check on login, when uid.<playeruuid> != <playername>, then the script would have to move from $oldname.vars to $<playername>.vars and delete the old object. This is not as easy as I hoped it to be. Good thing there is still time until name changing will be implemented.

@Lyoko_Firelyte

I thought of that, too, but I had in memory that VT had issues if you supply an object variable as the second argument. This was possible: @SETSTR $some.string <var:$some.string>, however I'm already using a functional placeholder inside my moving script, so that wouldn't work. However if you tell me that what you said definitely works, no problem. I will be testing.

Is there an easy way to move an objects variables to a new name?

@IF @Online.Players ?= <cmdarg:1>

isnt working. Help?

I have join/leave events adding each player and removing duplicates, so all the names are in there but the script never states the above IF as true even when the player IS online.

In Script Commands documentation, "Also check if something is in the list with @IF @player.list ?= WinneonSword"

If anyone can give me suggestions, please read my new discussion in the forums;
What is the best way to get VT to update from Trigger.yml files?

@Lyoko_Firelyte

In the future will it ever be possible to use @CANCEL in the middle of a trigger (Instead of just the first line)

@JoelMinister Going back to the forums.

Now, @TP isn't working for me. It did work before but every time I make a change to my area trigger it quits working. Then after several hours of fiddling with it, it starts working again. If anyone can help, Use this link to my full issue discription in the forums.

Addendum: Found my problem. It was a real strange fix.

@JoelMinister

You are quite right. I'll start a thread in the forums tomorrow and post a link here.

The reason I started posting my issues here is that no one hardly goes to the forums. There are postings in the forums and tickets submitted there that are over a year old without acknowledgement let alone being answered. That's why I started posting my issues here. Everyone lands on this page and most take interest as to what's being posted. Even a bad response is better than no response at all.

@AncientTom

I think we're spamming up the comment page here :P maybe start a thread and post a link to it on here and we'll carry on there?

I have just stumbled onto, again, the problem of using a variable to set an integer paramiter.
@SETBLOCK $Door.Int1:$Door.Int2 <var:$Door.Location> I get must be integer message.
@SETBLOCK <var:$Door.Int1>:<var:$Door.Int2> <var:$Door.Location> No error messages and no block modified by @SETBLOCK. This only works with hard codded integers.

The last time I used @SETBLOCK for automating doors I had to create an eighty-three line subroutine to replace 4 lines of script to open and close a door because @SETBLOCK will not accept varibles. It would be nice if we could use variables here to.

@JoelMinister

I am beginning to feel like the boy who cried wolf with all the problems I have been having with VT. Some of them have been caused by assumptions and over sites on my part. When I start blogging for answers, it's only after I have exhausted all possibilities that I can think of. Sometimes there are things that I overlook, but that's why I come crying for help.

My assessment, as it stands now, after a full day of trying every conceivable syntax variation, I have concluded in my mind that <signtext::> will not work using variables. Variables within <signtext::> do not get evaluated unless they are contained within a <var:> placeholder. The placeholder requires a space to be present before <var:>. <signtext::> does not allow spaces in the coordinates argument. Therefore the only way I have been successful in reading a sign is to hard code the statement, <signtext:-124,41,-579:3>. <signtext: -124, 41, -579:3> will not work. :(

This is a very important addition to VT's arsenal if there were any way to use variables to pass arguments into it. Either removing the "space before" requirement for <var:>, have <signtext::> allow spaces in it's arguments, <signtext::> be able to evaluate the coords from a string variable, or get <signtext to accept variables without the need of wrapping them in a <var:> placeholder would fix this.

@JoelMinister

I have tried that several times and the only way I can get VT to evaluate the integers inside the variables is to wrap them in a <var:> placeholder and add a space before each <var:>. The problem is, that <signtext::> will not accept any spaces in the coordinates argument. Besides, you are feeding it a string and <signtext::> demands comma seperated integers.