• 0

    posted a message on Mana bars for Grid2?
    Quote from slickwalker
    Forgive my noobness, but I wasn't even away GRID2 could do something like that! That actually suits my needs perfectly.

    The defaults have a mana warning with a blue color on the border at 75%
    Posted in: Grid & Grid2
  • 0

    posted a message on Mana bars for Grid2?
    There is a ton of other stuff to do so this has not been converted yet. If you need to see mana just set up a regular mana warning for say 75% or something.
    Posted in: Grid & Grid2
  • 0

    posted a message on [Grid2] Possible bug...
    Ok I forgot a step: reset your saved variables. Under Grid2/options/Debugging. Click Reset. It will nil them out and reload your UI. After that if you get an error post it. If you can narrow it down to the steps you take after a reset that produces a bug it is even more fantastic.
    Posted in: Grid & Grid2
  • 0

    posted a message on Grid
    Quote from cerbul
    ...You mean the transparent health bar that shows how much health the unit will have after receiving a heal? Is it able to show the overheal?

    I am curious why you care to see theoretical overheal. Actual overheal can only be determined after the fact when the unpredictable damage the boss did during the heal casts shown is taken into consideration. With other words, the "overheal" bar could be twice the health of the tank and yet the tank is already dead because it will not be enough to cover the damage the boss is about to do.

    For me the usefulness lies in having it show who is getting heals at that moment, and do the heals top the person off. For example during aoe or right after some mass damage event.

    Having the incoming heals be the same color as actual health but with more transparency makes it easy to differentiate. I am pretty sure you can do that in both Grid and Grid2.
    Posted in: Grid & Grid2
  • 0

    posted a message on [Grid2] Possible bug...
    Quote from acoon
    ...I'd like to investigate a bit more...

    All right, the first steps are to install BugGrabber and BugSack. You probably also need some kind of LDB viewer. If you do not have one I would recommend SexyMap. Not only is it a great minimap mod, it will make your minimap sexy!

    Next, follow the links http://www.wowace.com/addons/grid2/ to the Latest Versions. If you use the Curse Client, make sure you set it to get the alpha versions. Right click on all the Grid2 mods and select Preferred Release Type / Alpha.

    After installing those and restarting WoW you should be able to see the error that prevents your paladin from working. The Bugsack icon on your minimap will change from green to red. Clicking on it will show you the error(s). I am most concerned with the very first error. Copy & paste it here.

    One last thing: reset your saved variables. Many of the changes are bnot backward compatible. Under Grid2/options/Debugging: Click Reset. It will nil them out and reload your UI. If you are unable to open options then you can quit wow and under C:\Program Files\World of Warcraft\WTF\Account\<YOUR ACCOUNT NAME>\SavedVariables delete all Grid2 and Grid2Options files.
    Posted in: Grid & Grid2
  • 0

    posted a message on PeriodicTable-3.1
    Quote from serious2
    I am adding items. I don't know how to operate the miner...

    You need to read and understand the instructions on how to modify PT3. What you are doing at the moment will not result in lasting changes.

    http://www.wowace.com/addons/libperiodictable-3-1
    Posted in: Libraries
  • 0

    posted a message on Grid2 - What it is, and what it's not
    I need to work through the issues still.

    Getting back to the paladin thing: Grid2AuraGroup has healing-prevented etc at the moment. It would make sense to add something for mitigation as you describe. corner-bottom-right seems like a good spot for it. If you have the spell ids for them I can throw one together. There may already be something like that in Grid as well.
    Posted in: Grid & Grid2
  • 0

    posted a message on [Grid2] The three threat colors.
    Excellent. As additional explanation, these are the 3 values the Blizzard threat api returns. The loosely tanked ones will show up during tank switches, especially if something goes wrong or during taunt while one tank is building up aggro.

    The (red) ones show up usually when adds arrive and initially target random people by proximity, heal aggro, etc. On boss fights I do not recall ever seeing it before a non tank pulls aggro and gets one-shotted. In toc vs the pvp bosses you will see a lot of it as well.
    Posted in: Grid & Grid2
  • 0

    posted a message on [Grid2] The three threat colors.
    Lets do it this way. I checked in a new alpha that has description text for these 3 colors. Please take a look at it and if that does not clear it up post again till we get it right.
    Posted in: Grid & Grid2
  • 0

    posted a message on Grid
    Quote from james31
    ...Except this information is only visible if output to the center icon...
    This kind of thing is why Grid2 is a little different behind the covers. It is however still alpha in many respects so you are stuck with how Grid does it. The center icon is Grid code, the other icons are plugin code. It could be unified in Grid (I spent some time trying) but it is a lot of work and at that point you are really just writing Grid2.
    Posted in: Grid & Grid2
  • 0

    posted a message on Revelation
    There is a weirdness on first use. It seems to sometimes use (the other profession?) the very first time Revelation is used. I have encountered this right after login and sometimes hours after login. Usually the mats are missing (so creating JC runed gems fails because there isn't enough taloring cloth available for example), but sometimes expensive unwanted gems are created.
    Posted in: General AddOns
  • 0

    posted a message on Grid2 - Layered Preferences
    Quote from Nich
    ...if Grid2 were shipped with a global account layer, by default, what specific information would conflict between one person using a healer and one person using a dps class?...

    Let us imagine a warrior, druid, shaman, paladin and priest sharing an account and thus having their options lumped together.

    The buffs which default to side bottom would work for the particular class. So for druids the brown square goes away if thorns is present and the yellow one goes away if mark is present. The buffs from all the other classes will also go away IF such a class is in the group / raid and they do the buff. Otherwise there will be a large layer of stuff there that will never go away. Worse, there is no account specific settings, so one of these "dead" statuses would be the top layer and obscure the other ones.

    Now move on to the other stuff. All the druid stuff gets added. Now as you point out this is not fatal, it only shows if you cast the spell for most of them. Swiftmend would always be there if there is a rejuv or regrowth on a unit. Similarly the various paladin and priest shields will always show. The dispellable curse / poison / magic / disease will be some combination based on the classes you have logged in with and have nothing to do with your class.

    Meanwhile the poor warrior just wants to see aggro so she can intervene / taunt or whatnot + Battle Shout or Commanding Shout not being up for someone so it can get reapplied. Instead she is seeing some random set of stuff of interest only to specific healers. In addition, the grid is gigantic to accommodate healer settings instead of tiny and warrior specific.

    Lets imagine that we rewrite all these so that they magically do different things based on which class is using them. You can get close to a reasonable setup but each status now has custom settings for each class. Oh wait, the layer thing already gives us that.

    The bottom line is this. You can go the old Grid route with separate settings for each class / spec. There is no sharing of common settings. There is no making minor tweaks of a basic setup to get to a custom class setup. There is just a game of making some setup, copying it around and tweaking it. If you want to make major changes you repeat that or individually log each class and repeat the same changes a number of times.

    Or you can have a layered scheme that lets global settings be global; class settings be class specific; custom settings be custom. All of which coexist happily. If you are having a setup issue with some character you look at settings for that character and fix it. You do not have to debug some ridiculously complex setup which could potentially be 18 specs per server.
    Posted in: Grid & Grid2
  • 0

    posted a message on Grid2 - Layered Preferences
    Quote from Gaff3
    ...If one layer is too trivial, could we at least limit it to account-><class> out of the box?

    I think you need to think this through from the following design goals:

    1) The runtime is completely separate from the load on demand options. it includes only the necessary code and data for Grid2 to work (after initial setup) without loading any options. The goal is performance.
    2) Grid2 has strong working defaults. Grid2 and its enabled plugins automatically configure themselves into a working configuration with no setup required other than maybe sizing and placing frames to your choice. The goal is a working setup using your chosen plugins, customized for your class / spec.
    3) Since Options are separate and load on demand we are not concerned with code size / complexity etc. except as it impacts maintainability. The goal is to save setup time.

    Everything else is optional. You can completely rearrange all indicators and statuses to taste.

    Now how will this eventually work out. I think for dps classes you will get account / dps / class settings. Class will likely be limited to the raid buffs your class can provide, and show on units that lack your raid buff or its equivalent. With other words account / dps will be the setup with possibly some class specific stuff. Note that currently dps classes show all kinds of stuff that will go away.

    For heal classes the current setups acquire a heal layer. So account / heal / class / spec. Multiple specs can be set up / chosen from by default. Perhaps the options even sniff your actual spec to figure out what to choose for initial setup.

    Now imagine that instead you only have one layer like account. Well now what. Nothing works unless you only have one character. Or you are back to having to set it up from scratch like in Grid. This is unacceptable imo. Even a two layer scheme is bogus. account / heal and account / dps may allow dps classes a mostly complete setup but it totally shafts healers.

    Your proposal breaks everything that is good about Grid2Options (point 2 above). Worse, if somehow you set up into some limited layer scheme, what happens when someone chooses all 4 layers? They are now looking at a setup mangled into 1 or 2 layers and somehow the code has to back that out and set it up for 4 layers and still respect the choices they already made. Ugh, no thank you, this is not an AI project.

    Worse, with only 1 or 2 layers that means all settings for multiple characters bleed into each other. Or the settings are account / custom or just plain custom for each character. Well at that point you have just implemented AceDB right?

    Lets look at it from a different perspective as well. Install SOCD (Sick of Clicking Dailies). This is an absolutely wonderful mod and saves me from doing stupid useless clicking in the blizzard interface. By default it sets up an AceDB with (unfortunately) individual settings per character. This is easily changed to using the same profile though at which point the power of AceDB shines through because it excels at a single setup across all characters.

    Now contrast that with Grid & Grid2. It is totally unworkable because you have individual settings, especially for the heal classes. You can go with an AceDB approach like Grid with individual settings per class and spec. That sadly makes users manually spread global changes around though.
    Posted in: Grid & Grid2
  • 0

    posted a message on Grid2 - Layered Preferences
    Quote from Gaff3
    ... a panel for configuring whatever layers the user wants, and what layer the current class / spec should be set to? I think this is a much stronger solution.

    The actual lib already supports this. However I just do not know if it is something we want users to do. It is maybe ok for a math phd, but we need this to work for regular users as well.

    The bottom line is this: are there enough and appropriate layers to solve 95% of the issues. If your heal / dps layer is added between account and class I think the answer is yes.
    Posted in: Grid & Grid2
  • 0

    posted a message on Grid2 - Layered Preferences
    Haha no, while i like multiple inheritance in code, there is no way I want it here. The alternative, where a plugin has options to apply a set of defaults via code is more to my taste.

    The actual layer lib supports two types at the moment: layers and mappings between two layers. Likely a third type would be supported that simply provides a choice without layers. That is, something identical to AceDB.

    To provide defaults in that scenario there would be a defaults system layered on top of everything. So basically each individual object type would register a default which would be the first layer that gets flattened (ie it resides above account etc.) This is already on the ToDo list since currently such defaults were moved into the objects themselves in order to get something working.
    Posted in: Grid & Grid2
  • To post a comment, please or register a new account.