Runes of Magic US / AU

Conclusions From Test Results

After doing a couple of tests (see [thread=77961]The FuzzyDIYCE Tests Thread[/thread]) and thinking about the results, I've decided a couple of changes are in order (only affects how the internals will work).

First, as noted in the item drag test, trying to read the required information from a dragged action bar slot is a pain in the [BLEEP] so instead, I'll just have something the user can select in the GUI to indicate which action bar slot they want. This also solves the problem for pet action bars etc, since you can't drag pet skills off of the the pet action bar anyway. Also, you can't drag pet skills from the skill book (tab 5) so something will need to be done for those as well (maybe a drop down box or something).

As to the pipe execution test, well it sort of went as planned, but the main annoyance there is the global environment thing I implemented (and talked about previously in this thread). In the end, the environment was to create a code apartment for the compiled skill scripts. Unfortunately, since those need to be converted with the loadstring command, this means that the scripts are always compiled into the global environment (that is just the way loadstring works). Meaning that most of the advantages that I wanted to gain from the custom environment are automatically lost. I'll likely just ditch the environment thing and just use the namespace trick since it'll simplify the coding. Ahh well "thems the breaks" as they say.

Thoughts on Localization

Since FuzzyDIYCE is going to have a GUI, we are going to need to think about localizations (i.e. language translations) for the GUI itself.

There are several ways we could implement this, but I think the easiest would be to have the game load the appropriate language file(s) at add-on load. If a different language is desired, this can then be loaded once the FuzzyDIYCE settings are loaded. We can get RoM to load the desired language file by using a special token within the add-on's .toc file.

The game recognizes a few special tokens when it deals with .toc files. For language localization, we can use $language and this will be replaced with the current two to four letter language identifier the game uses (e.g. "enus" for US/Canada English, "eneu" for UK English, "ru" for Russian, "de" for German, etc).

So all we need to do is create a bunch of files for each possible language, and have the game load the correct one. As I can't speak/write most of the languages possible, I'll just put copies of the US/Canada locale in all the other languages and let others create the appropriate translations.

For FuzzyDIYCE, I'll create a sub-folder called locale that will contain a sub-folder for each language named by that two to four letter locale identifier and put all the required language files in there.

So the folder structure would look something like this:


So to load a language file called translations.lua, the .toc entry would then be:


So now all we need to know is what are all the possible language translations. Looking through the .fdb files (yes, I'm a bad boy ), we can see all the following language IDs (probably not all are used or needed, but hey...)


Some of these languages may require a right to left text, not sure how or even if I want to deal with that.

Just a quick status update.

I've been crazy busy at work so progress is going a little slower than I'd like.

Hoping to get a better execution pipe test with more commands and possibly the beginnings of the framework for the plug-in/extension system soon...ish. But right now well ... brain-no-work! (took me a few minutes just to write this little update post... <sigh>)

Some Data Vars


Here are some cached data variables I'm thinking of implementing (names shown here are descriptive and not the actual var name). More will likely be needed, and some may prove pointless. Everything is subject to change.


Let me know of other pieces of information that would be useful to implement.

• Have Target[INDENT]Does player have a target?[/INDENT]
  
  
• Unit Alive/Dead[INDENT]Is target/party/raid/focus dead?[/INDENT]
  
  
• Unit Health Value/Percent[INDENT]Get the player/target/party/raid/focus/pet health as a value or a percentage[/INDENT]
  
  
• Unit Mana Value/Percent[INDENT]Get the player/target/party/raid/focus/pet mana as a value or percentage[/INDENT]
  
  
• Unit Sec Mana Value/Percent[INDENT]Same as Unit Mana but for the secondary class
  [/INDENT]
  
  
• Unit Has Buff/Debuff[INDENT]Does the player/target/party/raid/focus/pet have a specified buff or debuff on them?
  [/INDENT]
  
  
• Unit in party[INDENT]Is player/target/focus in a party?
  [/INDENT]
  
  
• Unit in raid[INDENT]Is the player/target/focus in a raid?
  [/INDENT]
  
  
• Player in combat[INDENT]Is player currently in combat?
  [/INDENT]
  
  
• Unit is Enemy[INDENT]Is the target/focus an enemy unit? (can be attacked)
  [/INDENT]
  
  
• Unit is type (player/critter/boss/elite/self/mob/npc/other)[INDENT]Is the unit one of the types above? (some types shown may not be identifiable)
  [/INDENT]
  
  
• Skill on Cooldown[INDENT]Is the given skill on cooldown?
  [/INDENT]
  
  
• Item on Cooldown[INDENT]Is the given item on cooldown?
  [/INDENT]
  
  
• Action button on Cooldown[INDENT]Is the given action button on cooldown?
  [/INDENT]
  
  
• Action button is usable[INDENT]Is the given action button usable?
  [/INDENT]
  
  
• Pet Summoned[INDENT]Does the player have a pet summoned?
  [/INDENT]
  
  
• Pet Doing Action[INDENT]Is the pet currently busy doing something?
  [/INDENT]
  
  
• Number party/raid players[INDENT]Number of party/raid members
  [/INDENT]
  
  
• Unit Primary/Secondary Class[INDENT]Name of unit's primary/secondary class
  [/INDENT]
  
  
• Shift/Alt/Ctrl key down[INDENT]Is the Shift, Alt or Ctrl key being held down?
  [/INDENT]
  
  
• Zone[INDENT]Name of current zone
  [/INDENT]
  
  
• Party/Raid Leader[INDENT]Unit is the party/raid leader?
  [/INDENT]
  
  
• Is Behind[INDENT]Is player "behind" target? As there is no clearcut way to figure this out, I'll use the same method that DIYCE uses (check if your target is targeting you)
  [/INDENT]
  
  
• Can Silence[INDENT]Can the target be silenced?
  [/INDENT]
  
  
• In melee range[INDENT]Is player in melee range?
  [/INDENT]
  
  
• In pvp[INDENT]Is player in PvP?
  [/INDENT]
  
  
• In siege[INDENT]Is player in Siege War zone?
  [/INDENT]
  
  
• Available Ammo Equipped[indent]Amount of ammo currently equipped
  [/indent]
  
  
• Ammo Name[indent]Name of current equipped ammo[/indent]
  
  
• Bag Item Count[indent]Total quantity of a given item (by item name)[/indent]
  
  

Nice one. Added it to the list, and it also made me think of a couple of other ones that may be useful (Ammo name and Bag Item Count).

Quoted from "Ravesden;583519"

• Boss
  
• Elite
  

Check the Unit Is Type entry

Quoted from "mrmisterwaa;583609"

In Instance?

That would be good, but I can't think of a way to actually detect that condition ... well short of having a table of all instance zones and looking up if you are in one of them.

EDIT:

Think I found a way using the table lookup and the world map. I'd need folk to do some testing in instances to make sure though.

Anyway, I'll put the test in the tests thread.

More Thoughts on Localization

So another potential localization problem occurred to me. If attempting to share a FuzzyDIYCE skill rotation on the forums, there is the possibility that someone from another locale would want to try it. This presents a problem since skill and item names will not be called the same across differing locales.

The only solution I can think of for this problem is to use the ID of the skill/spell/item/whatever instead. The IDs should be consistent for all locales and any names needed can then be pulled from the game when the add-on is loaded.

The above would also apply to buff and debuff names.

Thoughts anyone?

Quoted from "Noguai;583708"

To make these things global, you'll definitely need IDs. I didn't follow everything, but if I remember right you wanted to do something with skill drag 'n' drop which didn't work to well. So you probably want the user to type in the skill names?

Drag and drop worked fine except for two things. Dragging action bars is problematic (including pet stuff) and dragging from the skill book requires a special hook function. The action bar stuff will therefore use a drop-down or something for the action bar slot. The second, is already done since the hook was created for the test.

Quoted from "Noguai;583708"

How about scanning the locales in the ID range of skills and build a lookup table with the resulting skill name as key and an array of the possible IDs as value? I don't know if it's possible to get the skill IDs from the skill book.

GetSkillHyperLink() is the way to go. Once you have the link, extract the skill/item/whatever ID from the link. So not a problem there either.

A Couple More Commands to Implement

Hiya folks!

I'll be getting to more FuzzyDIYCE stuff soon, just need to rest a bit 'cause after 12 consecutive work days, I'm beat!

Anyway, a post by mrmisterwaa in another thread made me think that FuzzyDIYCE could use a text output command. And since there will be a GUI and therefore frames, we could also do some on-screen text messages.

Yet another possible text display option is to use the scroll banner display. It has been quite some time since I fooled around with that thing, but it used to be possible to add your own messages to it (only viewable by you not the world, mind).

So here's the commands as I'm thinking about

Simple Text Message in Chat Window (message)[INDENT][/INDENT]

On-Screen Message (screenmsg)[INDENT][/INDENT]

Scroll banner message (bannermsg)[INDENT]
[/INDENT]

Edit
Did a quicky test in-game using the following:


With the above, try typing these in the chat box (or use a macro)


Banner 1 has the red background, banner 2 has the blue background, banner 3 has a green background and banner 4 has the grey background.

Each call to a given banner will add the message to that banner's message queue.

There is enough room to get two lines of text scrolling across (try adding a '\n' in the string to put a carriage return.

Color codes also work in the text for the scroll banners.

Quick project status update:

Currently still testing/debugging a few things, but FuzzyDIYCE will be moving into the next phase very shortly.

Stay tuned...

FuzzyDIYCE Phase II: The Core

Though I originally intended to just make another test of the execution pipe, things were going so smoothly that I decided to simply bite the bullet and move the project into the next phase. Basically full development.

Yes there are quite a few questions still to be answered, and there are still things that need to be re-worked (such as how the cached data variables work). But my feelings are that it would be beneficial to actually get more than a few obscure test files out.

So I present to you the pre-alpha version of the FuzzyDIYCE core (currently available in the test release thread).

Enjoy!

An Annoying Problem...

I've been adding the Plug-in system to FuzzyDIYCE Core and encountered a rather annoying problem.

To allow others to more or less easily add plug-ins modules, I decided to take advantage of a couple of obscure but useful properties about how the game loads add-ons. The first being that when the game loads an add-on, it actually will load any and all .toc files in the add-on's folder. The second is that when the game does this, it opens the .toc files in lexicographic order.

This then would be perfect for the plug-in system since anyone wanting to make a plug-in can put it in the correct sub-folder and place a .toc file in FuzzyDIYCE's add-on folder. FuzzyDIYCE itself would have the plug-in system load prior to anything else, and have the core itself load after everything else. This way, everything is loaded by the game, and in the correct order.

This does indeed work, and will effectively be what I'll use for FuzzyDIYCE, but that actually leaves me with the problem.

I do not run Windows but Linux and therefore run the game through Wine. Unfortunately, I found that Wine has a wee problem and doesn't do the lexicographic order that is present on real Windows systems. This means that for me (and anyone else running Linux) I either need to make a special version of FuzzyDIYCE, or live with the fact that this add-on will simply not work for Linux users. It is a truly annoying problem that is going to slow down development.

This problem isn't the game's fault, nor Linux's for that matter. It is Wine that is problematic. I can still run the game in a virtual machine, so this doesn't mean that development is coming to a stand still, it is just really annoying for me and anyone else running the game through Wine.