VariableTriggers

Make your own plugin like features and more using VariableTriggers
This is a very powerful plugin that has unlimited potential. Create triggers that run lines of script when a player Clicks or Walks on a block (dirt, door, switch, trigger, torch, any block) or Create Event Triggers such as PlayerDeath , EntityDeath, BlockBreak, BlockPlaced, Join, Quit, Respawn, Interact and EntitySpawn that also run scripts. You can define Area Triggers and Command Triggers as well. You can use Dynamic Object variables and conditional IF and ELSE statements in the scripts. You can run any command that a player or OP can run and many speacial built-in commands to Teleport, Spawn Entities, Play Effects Visual or Sound, Set Blocks, Toggle Blocks, Check Players Heath and much more!. The scripts are executed on their own threads to take the strain off of the main server thread.
















-
View User Profile
-
Send Message
Posted Jun 1, 2014would this work to open up the TARDIS Plugin sonic and key GUI's? link http://dev.bukkit.org/bukkit-plugins/tardis/#comments
-
View User Profile
-
Send Message
Posted Jun 1, 2014Can someone help me please. I'm trying to do this: When a player goes into an area, he's teleported to a location (command execution /tp @p or /warp ...), is it possible to do that with this plugin ?
Thanks
-
View User Profile
-
Send Message
Posted May 31, 2014Currently working on a new update with some changes you guys have requested, should be done shortly :)
-
View User Profile
-
Send Message
Posted May 30, 2014@Heterosapien
At present the answer is no
-
View User Profile
-
Send Message
Posted May 30, 2014Is there a way to determine if there are enemy mobs in a specific area? Not just in the radius around the player?
-
View User Profile
-
Send Message
Posted May 30, 2014@Kiak
This is exactly how I've been doing it. The code inside that if can either check the light level or if a block has been placed (you can use the command block to place a block in a hidden location).
-
View User Profile
-
Send Message
Posted May 30, 2014@H8llfire
Oh okay, well thanks for filling me in.
in that case Lyoko start coding all these replacements.
How dare you even have a life..
/Gets out his whip.
-
View User Profile
-
Send Message
Posted May 29, 2014@Kiak
The latency only applies if you ask for offline players, as bukkit caches all the UUIDs. The time it takes to fetch these is also not very long, you don't even notice it on serverjoin, as the session checking also takes its time.
What you said is basically how I arranged myself now.
-
View User Profile
-
Send Message
Posted May 28, 2014@H8llfire @H8llfire
I thought the UUID call thing involve some amount of lag/latency while it checks the server?
Aren't you still going to be better off Checking playername Versus UUID at JOIN... and then making an Array of those [(Playernames),(UUID)]
Then you can continue to use your <playername> <killername> etc because you'l know that noone's using a fake name from the ON JOIN uuid check...
Have I missed any good reason why this won't work?
-
View User Profile
-
Send Message
Posted May 28, 2014@Lyoko_Firelyte
You mean like a script command @RENAMEOBJECT or something? Why not, does VT use a Map Matrix to store the vardata? Shouldn't be to difficult to move all the data over?
-
View User Profile
-
Send Message
Posted May 28, 2014@Lyoko_Firelyte
I would ask more for UUID commands honestly. I understand some people could have problems with their existing scripts, but VT really needs to get to the point that it's fully compatible first. Basicly anything that uses playername needs to be UUID too for it to be functional.
If you add full UUID functionality, people can write a name to UUID transfer script;
On join, check $<uuid:>.Transfer, if false, make UUID object with a string for their name and set it to true.
Also on join, if $<uuid:>.Transfer = true, set name string to current name.
If you know all the strings and integers you need to use, then if transfer = false, set $<uuid:>.whatever to what $<playername>.whatever was.
It'll convert those who do join and it should pre-set a few variables for those who have newly joined. Yes it would be extremely variable heavy, but so is doing over a thousand users by hand.
If you give me more time later I'm sure I can make an actual example, but it is possible. :)
Honestly, MCore and Factions updated, so now I'm waiting for Essentials and VT.
Seems H8llfire and I think alike. ^_^
-
View User Profile
-
Send Message
Posted May 28, 2014The uuid thing is really a giant headache. I can think of a lot of ways to remedy this in Java, but VT does not really have the necessary functions to make a name update possible. If anyone thinks of anything I can write in to make this easier, please let me know...
-
View User Profile
-
Send Message
Posted May 28, 2014@Kiak
Lets say I have a variable $<playername>.killcount When moving over to uuid, I could write a script that moves the object <playername> over to <playeruuid>, making this variable $<playeruuid>.killcount.
This would be no big issue, however when trying to access it again, through the playerdeath event for instance, you would have to use some kind of uuidcache, like $uuid.<playername>, which will be created on join. This would lead to the variable <var:$uuid.<killername>>.killcount to be used in this script. I think that this would still be valid, however when making conditional checks or even having to use <cmdarg:> funcplaceholders, this wont work anymore. I now arranged myself with a script that checks stores the players uuid and onjoin checks if the name changed, if it changed it will move all the variables over to the new Object.
-
View User Profile
-
Send Message
Posted May 28, 2014@H8llfire
I haven't really looked into this much but......
Wouldn't you just check out their uuid at Join and then write a variable storing their name which you can use for all future checks?
I dunno, I would just wait till we get to the bridge before trying to cross it myself.
-
View User Profile
-
Send Message
Posted May 26, 2014Hi, I am still struggling in finally being able to move over to UUIDs, as a lot of functionality will break with the transition to them.
At the moment data about a player is stored in Objects $<playername> obviously, moving over wouldn't be a problem, as long as we don't have to use functional placeholders to be able to call them. I reported a ticket about the <uuid:> placeholder not working in Objvars which seems to have been ignored.
It would be nice if we can get more nonfunctional placeholders to obtain users UUIDs.
For instance, not just <killername>, but also <killeruuid> to make the pvp scripts working properly. This would be great! And a working <uuid:> placeholder would be great, too ;)
regards! Lyoko you are doing a very nice job, thanks for taking over the development. (however, <eval:> still prints debugging messages to the console and the color codes in console are still buggy ;))
Edit: whatever, arranged myself another way. Keep it up!
-
View User Profile
-
Send Message
Posted May 26, 2014@james070508
Your best bet is to make your life easier by using scripts.
Eventtriggers.yml
^ Script might not be perfect cause I did it off the top of my head.
then at least you only have to type one line per world. and you only have to change the MOTD in one place.
-
View User Profile
-
Send Message
Posted May 26, 2014@james070508
Currently the script uses the world check to determine if it should listen, so a global event won't work.
-
View User Profile
-
Send Message
Posted May 26, 2014Hi, My MOTD is ran by vTriggers for customisability purposes, EG random messages etc.
Currently we have to add a join event to every world. This does work however is there a way to make a global join event?
Thanks
BTW, thanks for the updates to vTriggers! My whole server is basically glued together by it and i'd be lost if I didn't have it haha
-
View User Profile
-
Send Message
Posted May 24, 2014So... you guys like the job Lyoko_Firelyte and Kiak are doing?? Don't forget to throw some complements their way.
-
View User Profile
-
Send Message
Posted May 23, 2014@TehSaltyOyster
@CMDCON give <playername> 1 1