GSE: Sequences, Variables, Macros

GSE: Sequences, Variables, Macros

6M Downloads

[ENH] New Disable Editor mode: Restriction for Sequence, but not Variables

revelation343 opened this issue Β· 9 comments

commented

🟒 How does GSE currently work
I know that you recently fixed the ability to remove restrictions through disabling the checkboxes and re-importing the macro. I was one of the people who reported it to Gaupanda in the first place. The Disable Editor method currently disables viewing tabs entirely, and I think this option should still exist if that is how authors want to handle it. So I am not asking for that feature to be removed.

🟒 Describe the solution you'd like
While I do not do any coding for WoW, I was able to piece together based on my java knowledge how to get the restriction removed by reviewing the GSE github and using some critical thinking. My solution is to add a new restriction method i.e "Disable Editor - Allow Variables" or however you'd name it. This would be an option for authors that still lets us view the tab(s), restricts access to the "Sequence" portion of the tab whether it's just blacked out or simply doesn't show at all, but allows the "Variables", "Use", and "Resets" sections to be viewed and edited for each tab within the macro. Or perhaps have variables as its own seperate tab like WeakAuras, though I think the former would be better as setting variables for each tab is generally a better experience based on the content you are engaging with. Whatever makes the most sense.

🟒 Describe alternatives you've considered
The only alternative after the patch is to try to use a downgraded version and hope WoW doesn't break it to unethically break the restriction, or request a custom macro from the author and wait for a response. I don't support the concept of using a downgraded version to break the Disable Editor restriction. I only investigated the possiblitiy of being able to break the protection after another user had claimed to break the protection in a Discord server, and then promptly reported it to Gaupanda who then spoke with you and raised an issue, which was promptly fixed. Kudos on that.

🟒 Additional context
What I have noticed is that due to the Disable Editor restriction in general, there are constant requests to change modifiers, etc. Authors then have to make custom macros for users to protect their sequence, etc. If this new restriction method were to be added, then I think we would have a win-win for authors who want to protect the integrity of their macro and prevent others from copying it, while also allowing users to make the very basic changes we need outside of the sequence i.e Ctrl/Alt/Shift modifiers, along with other keypress/keyrelease variable calls; Call pet 1/2/3/4, [noharm], [nocombat], etc. and trinket usage, without having to ask the author to create a specific macro for us every time they update the macro, then potentially not getting exactly what we requested, and having to wait for another custom macro.

At the end of the day, this is a very low-priority issue that only affects users that use macros from authors that utilize Disable Editor. One could simply say, if it's that much of an issue, find a different author! I think that this is just an enhancement, if possible, that would get rid of a lot of unnecessary conversations/debates surrounding the whole topic and let us utilize GSE the way it should be.

Thanks for everything that you do. GSE has been a staple point for me with arthritis and inflammatory issues since BFA. :) Sorry to come off long-winded. I don't post issues on github much and I just wanted to be as articulate as possible. If it's not worth the effort or time, feel free to close it, no worries here.

commented

This would be a great change for creators and would stop 99% of the problems with people wanting to change their MODKEYS to what they normally use.

commented

The issue isnt for what you are describing. The assumption is that a variable is just a bunch of text. What about the variables that look like:

function()
  local function GetDetailsDamage()
    local combat = Details:GetCurrentCombat()
    local damageContainer = combat:GetContainer (DETAILS_ATTRIBUTE_DAMAGE)
    local actorsAmount = GSE.NewTable()
    for i, actor in damageContainer:ListActors() do
      local amount = actor.total
      if (amount and amount >= 1) then
        local tempTable = GSE.NewTable()
        tempTable["name"] = actor:name()
        tempTable["total"] = amount
        tinsert(actorsAmount, tempTable)
      end
    end

    table.sort (actorsAmount, function(a,b) return a.total > b.total end)
    return actorsAmount
  end

  if GetNumGroupMembers() < 1 then
    return "@player"
  end
  -- Change the 2 in this next line to a 3 for Second Highest DPS
  local detailsUnitName = GetDetailsDamage()[2].name
  local unitName = detailsUnitName
  local prefix = IsInRaid() and "raid" or "party" 
  for k=1, GetNumGroupMembers() do
    local unit = prefix..tostring(k)

    local unitFullName = UnitName(unit)
    if string.sub(unitName, 1, string.len(unitFullName)) == unitFullName then
      return "@" .. unit
    end
  end
  return "@player"
end

100% of my variables look like this. The smallest change here can crash the entire game not just this template or GSE. This is a simple one but the results of some of mine are a /cast [@fred,mod:x] stuff line with mods at the end of them. I also have other simple variables like the ones you are describing above in the same templates. Where does the line draw that you can change one variable but not these ones?

commented

image

commented

That was a mess to figure out

commented

image

commented

Will certainly be appreciated by plenty of authors and users. Thanks Tim!

commented

Nice Job Tim!

commented

This issue has been open for discussion. For a while: #1003

Simple text variables are translated but it’s not as simple for when things are more complicated and they are function variables.

commented

This issue has been open for discussion. For a while: #1003

Simple text variables are translated but it’s not as simple for when things are more complicated and they are function variables.

What I am suggesting is Disable Editor remains intact and importing the macro users would receive:

image

Adding a new Disable Editor - Allow Variables option that authors could choose over Disable Editor, importing the macro users would receive:

image

Having read Issue #1003 I understand the complexities of translating basic text vs. function calling and how it would be inappropriate to translate all variables. I am not asking for that, I don't believe Disable Editor modifies anything with translation, but I may be wrong. Feel free to correct me.

I am just proposing a new Disable Editor - Allow Variables function that allows users of a macro, if the author uses it to share their macros, to see and modify everything in the second image, while keeping the restriction of Sequence hidden from users. The only change would be the difference between the first and second image.

Benefits:

  • Authors keep their sequence locked and hidden
  • Users can view/change the Variables, Use, and Resets sections in the macro
  • Authors would not have to create custom macros for each user based on their specific needs:
    -- Not having to ask to change modifiers
    -- Not having to ask for Trinket 1 to work but not Trinket 2, vice-versa, use both trinkets, use no trinkets
    -- Not having to ask for keypress/keyrelease variables to be translated by the author who probably doesn't speak their language in the event the author does not use Spell ID's during function calls in a variable.

Hopefully the images of the proposed addition illustrate what I am requesting better.