Runes of Magic US / AU

[HR][/HR]
[HR][/HR]
Welcome to the FuzzyDIYCE test release thread. Here you can find downloadable tests of various FuzzyDIYCE builds (complete or incomplete) as well as miscellaneous test add-ons for various things related to FuzzyDIYCE.

As the files found here are intended for testing, don't expect things to be fully functional. Read the description for the intent of the test before trying it out.

This first post will be updated with links to the posts for each test file.


Table of Contents[INDENT]Tests[INDENT][post=582651]Execution Pipe Test[/post]
[post=582786]Dragged item Test[/post]
[post=583685]Find instance test[/post]
[/INDENT]

Pre-Alpha[INDENT][post=584049]FuzzyDIYCE Core Pre-Alpha v1.0[/post]
[/indent]

Alpha[indent][post=585046]FuzzyDIYCE Core Alpha v1.0[/post]
[/INDENT][/INDENT]

Execution Pipe Test

This is a test of the techniques needed for creating and running the execution pipe. As there is no GUI editor nor "compiler" for the user edited code, a "source" version of what the editor/"compiler" would produce is hardcoded into this add-on.

Only the try command is partially implemented (only the action button part is done). The only other command usable is the invalidate command, but it merely displays the message that it isn't implemented. There are no cached data variables implemented as yet.

The test, as it stands doesn't actually create or use the timers, though they should work if the "source" skill list is manually modified.

To try this little thing, put some spell/skill in action bar slot 1 then create a macro with the following code:


Put the macro on an action bar and click it to trigger FuzzyDIYCE (the game's UseAction() function doesn't appear to work when run directly from the chat window, so it needs to be triggered from a clicked macro).

Expected behaviour:
Clicked for the first time, the spell/skill should trigger. While the skill is on cooldown, clicking the macro again should give the message "item use not implemented". In both cases, you should also see the message "invalidate called (not yet implemented)".

This then shows that the first skill gets triggered and the second is skipped while when the first skill is on cooldown, it is skipped and the second (the item use line) is tried. In either case the third line (the call to invalidate is called since that isn't a skip-able command).

When I tried this with a Priest regenerate spell in action slot one, I could spam the macro so fast that sometimes FuzzyDIYCE would try to trigger the skill just before it was off cooldown (giving the Skill on Cooldown message on screen). Will need to see if something can be done about this.

Item Drag Test

This test is for detecting/reading the required information from a dragged item/skill/macro/whatever.

The add-on displays a rectangular frame on screen where you can drag various things to it. The add-on will then display gathered information based on this.

As it stands, you can drag macros, skills, bag items, equipped items, and action bar slots.

To properly read the dragged skills, the add-on must hook into the skill book's normal drag start event handler, otherwise there would be no way to know what skill was being dragged.

The action bar buttons are problematic. There doesn't appear to be a way to consistently detect which action button slot the dragged item came from. Further, since dragging an action bar slot empties the slot itself, we can't even scan through the action bar buttons to attempt to find where it originally came from. For these reasons, the add-on doesn't clear the item in the cursor when an action bar button is dragged.

For this reason, I've decided that FuzzyDIYCE will not accept dragged action bar buttons. Instead, FuzzyDIYCE will simply have an editable field where the user can type/select the desired slot.

Find Instance Test

This thing is an attempt to find out if the player is currently in an instance.

If you do test this, please report any results either in this thread or the main development thread. I need to know if it find the correct instances or not, as well as if worked at all.

Load this as an add-on and when you are in an instance (or out), type this in the chat box:


If you are in an instance, it should display the the type, ID, and name of the instance you are in. (if you aren't, or it doesn't find the instance, it should do nothing).

Hmmm... guess I'll have to go find some other way. Thanks for testing.

Quoted from "marcelcrazy2;583902"

np, glad to help. anything else i can test i'll. sadly only way i can help.

But a rather important aspect to any development so it is appreciated.

Just want to make sure you did indeed run the function when you entered each instance (that test add-on doesn't do anything until you run it). My characters are too low-level to really hit any instances, but it did work for the Fungus Gardens world instance and the starter Tutorial instance (guess I really should spend some time leveling a few characters :p).

FuzzyDIYCE Core Pre-Alpha v1.0

Here you go folks. A pre-alpha version of the core of FuzzyDIYCE.

No GUI or code converter from user scripts to FuzzyDIYCE's internal script, and there are a lot of commands and variables still missing. But it effectively works, and in the basic code structure that I want it in (things mostly split logically into independent files).

The beginnings of how the plug-in system will work is also in place, though there is much still to be done in that area.

The cached data variables will need to be revamped because what is currently there is not enough for many of the data variables to be implemented.

This things spits out a lot of text to the chat window for debug/test purposes. Of course, these will mostly be removed when a real release happens.

I'm rather impressed so far with the execution speed of this thing, though that may change when more stuff is added in.

Anyway, on to how to use/test this thing.

First, if you have the old execution pipe test as an active add-on, get rid of it since it'll clash with this.

To start FuzzyDIYCE, the slash command has been enhanced to accept the name of the script you wish to execute. just typing /fdiyce will show you the basic usage which is


There are 13 test scripts pre-defined called (as you may expect) test1 through to test13.
The test scripts expects you to have a long-ish cooldown skill (a self-buff is good) on action bar slot 1, and a GCD only skill on action bar slot 2. These skills should not require you to select a target so auto-self-cast buff skills are good.

Here's effectively what the test scripts do:

• test1 is a basic command test and will display a message in the chat window as well as on a scroll banner.
  
• test2 is a test of the try command by using action bar button 2.
  
• test3 verifies the basic functionality of the perform command by first adding a scroll banner message then calling the test4 script.
  
• test4 is intended for use by test script 3 and so only displays a scroll banner message.
  
• test5 verifies that the try command can block the perform command. It will try to use action button 2 then calls the test3 script.
  
• test6 verifies the opposite of test5. It checks if the perform command can block the try command. It will first call the test7 script then attempt to use action button 2.
  
• test7 tries to use action button 1. It's really here to be called by the test6 script.
  
• test8 will attempt to use action button 2 with a 5 second timer. This tests the basic timer functionality.
  
• test9 verifies that the cached data variables work correctly. It will read the GotTarget variable twice (for debug messages), invalidate the cache for that variable then read it twice again. The variables read are sent to the scroll banner (one banner for each read attempt). Lots of debug messages get sent to the chat window for this test.
  
• test10 will attempt to use action button 2 with the 5 second timer, but will ignore the timer if you have a target selected (use the GotTarget variable).
  
• test11 first execution speed test. Does various commands to check basic execution speed.
  
• test12 second execution speed test. It will do the following ten times: purposely fail to use the action button 2 (it has false for the use clause), invalidate the cache for the GotTarget variable (forcing it to update on the next read of the variable), using the GotTarget variable in an if statement (hence doing the actual variable update), and finally displaying a message to the chat window based on the result. BTW, the if statement in here will be what the when command will eventually produce, so it is valid.
  
• test13 the third execution speed test. This script will call test12 100 times.
  

Quoted from "marcelcrazy2;584235"

so, i've put savage power, 90s cd on skill bar 1, and Frost Arrows, only GCD on skill bar 2. both self buffs.

The first skill should be in the first button of the main action bar while the second skill (Frost Arrows in your case) should be on the second button. That is, the buttons are the ones with the numbers "1" and "2" hotkeys displayed on it.
If the skills aren't in the right place, the tests won't really make sense, or work correctly.

Quoted from "marcelcrazy2;584235"

test1 shows the scroll banner, chatmessage: exec time: 0
test3 calls both test 3 and 4 banners, exec time:0
test4 calls only banner test4 exec time:0

These are what is supposed to happen. In the case of test 3, it internally calls test 4. The fact that you see both banners in test 3 proves that the perform command worked.

Quoted from "marcelcrazy2;584235"

test5 only exec time:0, didn't call the banner from test3

You need to run it twice. the test tries to use action slot 1 and if it didn't it then calls test 3. If the action slot was used, it will not call test 3. Since that first action is on a long cooldown, the first time running test 5 should try the skill, the second time should run test 3 instead.

Quoted from "marcelcrazy2;584235"

test6 only exec time:0
test7 only exec time:0

This is effectively the reverse of test 5. Test 6 runs test 7 and then tries casting the GCD only skill. Test 7 tries the long cooldown skill. Again, this needs to be run twice (when neither skill is on cooldown).

Quoted from "marcelcrazy2;584235"

test2 only shows exec time:0 on chat
test 8 only exec time:0 only once.

With the skills in the correct action bar button slots, test 2 should cast the GCD only skill, as does test 8. The difference between these two tests is that test 8 puts a 5 second fake cooldown timer on the skill, so if you have a macro with /fdiyce test8, the skill will only fire every 5 seconds even if you spam the macro.

Again, the skills must be in the right slots.

Quoted from "marcelcrazy2;584235"

test9 calls 4 nil banners and all the chat messages

Another test where you need to try it under different conditions. When you run it without a target, the nil displays are normal. If you however select a target, the messages will change to true.

The chat window messages show further debug information about how and when it uses the variable's cached information. The first should force an update, while the second you simply read the value. The results of these two variable reads are displayed in the first two banners.

The test then forcefully invalidates the variable's data cache and repeats the same two reads. As before, it should then force a second update of the variable on the third read, but not the forth. The results of these last two data reads are displayed in the third and fourth banner.

Quoted from "marcelcrazy2;584235"

test10 just says it updates, and return cached values for gottarget

Test 10 is a little odd. Much like test 8, it casts the GCD only skill and also uses that 5 second cooldown timer on it. However, if you have a target selected, it ignores the fake cooldown timer allowing it to be spammed. It proves that the ignore flag for the fake cooldown timers function properly.

Quoted from "marcelcrazy2;584235"

test11 2 banners with their messages, few chat messages, exec time : 0
test12 chat messages, exec time: 0
test13 100s of repeated chat messages.

All three of these tests were for speed measurements though the exec time displayed doesn't appear to work. I used a different method.

Anyway, test 11 does a bunch of stuff that attempts to emulate what a typical script would do (more or less given the limited amount of commands implemented).

Test 12 repeats a sequence of commands in order to waste time (again to test execution speeds of the scripts themselves).

Test 13 effectively runs test 12 100 times! So yeah, you'd get a boat load of messages ;p

Quoted from "marcelcrazy2;584235"

well, i don't know if i did something wrong, but none skill was cast. neither of the 2 i've put on 2 first slotbars. and still couldn't make the /script FindInstance() to work.

Other than possibly having the skills in the wrong action bar slots, your test results appear to me to be correct.

As for the FindInstance thing, well that is another issue (I responded to your PM on that issue).

Very odd. The skills I've used to try this out originally are the Priest spells Soul Source for slot 1 and Regenerate for Slot 2.

I also have Self Cast turned on in the game settings (Interface Settings > Controls > Self Cast). If your skills need a target and Self Cast is not on, this might be the problem.

Just a quicky update on some test results for those curious about this.

Working with marcelcrazy2 in-game, we got the kinks worked out of the pre-alpha tests and determined that it is working fine.

As to the FindInstance test, it seems to mostly work but there are a few issues. First, marcelcrazy2 discovered that it doesn't work at all in WA, and some of the others it only will indicate you are in an instance after moving forward a bit into the instance. So some work will still need to be done there.

Much thanks to marcelcrazy2 for being the Guinea pig

FuzzyDIYCE Core Alpha v1.0

Here is the Alpha version of FuzzyDIYCE Core (still just the core).

As before, if you have the core execution pip test or the pre-Alpha already installed, you'll need to remove them first or they could interfere (there currently is no version system in place).

This version is much more complete (though still quite a few commands and variables missing) but you can actually create simple skill rotations using what I've come to call FuzzyScript.

There has been quite a bit of re-working of some of the internals, and the core's plug-in system is pretty much complete (at least I can't think of anything else it might need at the moment).

All the FuzzyScript commands and variables are now implemented as a FuzzyDIYCE Core plug-in as well as the test/demo scripts.

FuzzyScript itself is really intended to be what FuzzyDIYCE/RoM actually executes and what those who like to get their hands dirty can use. It may seem a little awkward to use for non-programmer folk, but fear not, the easy skill editing is what the GUI will be for. FuzzyScript will be what the GUI ends up creating behind the scenes.

Anyway, about using/testing this thing.

As before, create a macro with

where Script name to run is one of these demo scripts

• DemoMessages[INDENT]Displays a text message in the chat window and also displays a scroll banner message.[/INDENT]
  
  
• DemoTry[INDENT]Will try to use whatever is in action bar slot 2. If it is on cooldown, nothing happens.[/INDENT]
  
  
• DemoPerform[INDENT]This actually calls the DemoTry script via the perform command.[/INDENT]
  
  
• DemoTimedAction[INDENT]This also tries to use action bar button 2, but has a 5 second timer attached to it. Trying to spam this script should only trigger the action every 5 seconds.[/INDENT]
  
  
• DemoTimedActionSpammable[INDENT]Like DemoTimedAction but with the addition of allowing the script to be spammed (i.e. ignoring the timer) if the shift key is held down.[/INDENT]
  
  
• DemoTarget[INDENT]Demo of the target command. Will select the next enemy in range.[/INDENT]
  
  
• DemoExec[INDENT]This also calls the DemoTry script, but this time it uses the new exec command.[/INDENT]
  
  
• DemoDirectCall[INDENT]Once again this internally calls the DemoTry script, but this time it calls it directly (much like a Lua function).[/INDENT]
  
  
• VarTest1[INDENT]Demonstration of some of the new cached variables, will display your health and mana in a scroll banner, and if you have a target selected, will show the health and mana of the target as well.[/INDENT]
  
  
• VarTest2[INDENT]Uses the new template cached variable IsTargetType to display various things you can look for using this variable. Requires a target to be selected.[/INDENT]
  
  
• StringTest[INDENT]Again only displays some messages, but the script itself was compiled via a string as opposed to direct code.[/INDENT]
  
  
• StringTest2[INDENT]Shows that direct calling from a compiled string script is possible. This again calls the DemoTry script.[/INDENT]
  
  
• MagePriest[INDENT]A very rudimentary skill rotation (nothing fancy) for Mage/Priests just to show that yes, simple skill rotations can be implemented.[/INDENT]
  

Well other than the very small number of people testing, it has so far been quite successful. The alpha is still quite early code and not all needed/desired commands and variables are implemented.

As for update posts, well there is more recent posts in the development thread, though mostly only status updates as I'm working (and re-working) the GUI side of the add-on at the moment (and of course, life does like to stand up and demand attention).