Note: If I didn't add your issue to the git
board and you think it's important, feel free to add it yourself.
defaulted inis unless they edit/customize
An "out of the box" experience for KissAssist has been on the wishlist for ages. Let's make it happen.
https://gitlab.com/redguides/kissassist/issues/34
the ongoing slow rez issue
Added,
https://gitlab.com/redguides/kissassist/issues/35
Updating/Removing/Adding an Option for some hard coded things inside kiss --- like the SK auto-self summon - there is no reagent check for this, or toggle or documentation that this is a function/feature - and months ago they added the requirement for reagents for it - and there's no toggle off for this inside kiss! this adds huge headache for users who don't understand how/why/what. and they shouldn't have to comment something out to get it to function
Added,
https://gitlab.com/redguides/kissassist/issues/36
0) Fix KA so that spells with the name name as skills (e.g., Frenzy, Feign Death) still work.
Added,
https://gitlab.com/redguides/kissassist/issues/37
1) EQ Mule's ranger positioning code or a flag to enable MQ2Melee stick commands when using KA vs. them being turned off.
We could use some more detail on what is wrong with Ranger's positioning exactly:
https://gitlab.com/redguides/kissassist/issues/38
A general thing I'd like to see with a communal effort towards KA: An open discussion for various forks to maintain a common ini format in order to people to easily change flavors of KA if there's a specific 'fork' or custom version they'd rather run. This allows for divergent design views without considerable work re-engineering ini files.
The only major fork I know is eqmule's, any others?
https://gitlab.com/redguides/kissassist/issues/39
we need to cut some of the fat out....like the dps parser is not needed!
YES!! I added a "CUT THE FAT" label, removing the DPS parser is a good start:
https://gitlab.com/redguides/kissassist/issues/40
Example: writespells and memmyspells should just be an alias to a respective mq2cast function. This is a super simple example but I'm sure there's more like the above.
Another good "cut the fat" project!
https://gitlab.com/redguides/kissassist/issues/41
So, not to volunteer @ctaylor22 to more work, but I'd love it if we give me an editable post somewhere, or maybe it gets put in as issues to the VV repo, whatever ends up being best for workflow, where he just puts up a request every time he runs into something he thinks should be in a plugin. If it's a VV gitlab issue, we could at least have a discussion there on where it is best to go and then have someone start working on it as well as map it to commits.
It's best to use gitlab issues for this. Create the issue, and add the "cut the fat" label.
Tank goes out to pull, tags their pull target. Gets aggro on the way back. The aggro mob arrives to the camp before the pull target. Tank stands there waiting for the pull target instead of engaging the first thing in camp.
Good issue. Added.
https://gitlab.com/redguides/kissassist/issues/42
Rezes aren't dependable. Sometimes it rezes, sometimes it doesn't.
This seems like a big issue.
https://gitlab.com/redguides/kissassist/issues/43
I don't like that KA turns off MQ2Rez. I can see it changing the accept percentage to a reasonable value input into the INI, or turning it on if it wasn't already. But I don't care for the part where it turns it off if I've overlooked that entry in the INI. If MQ2Rez is arleady on and accepting rezes I'd like it to continue to do so. I've had mixed feelings about the situation because there is an option in the INI that allows it to be set to on/off and to set a percentage that it does it.
Could we move rezzing back to MQ2Rez? Is this another plugin mistrust issue @ctaylor22?
Having been writing plugins for a whlie now. I've seen the responsiveness of the pass through functions where waiting isn't an option. That is to say that if you can change things in the main routine to be "pass through" type functions where it either does something or moves on allowing a consistent loop during combat, with the option to reset to the top of the loop after every action, it would allow for healing to be place on the top of the priority list, followed by mezes, followed by everything else in some considered order. Using this method for my plugins allows it to instantly recognize low health, that the group has aggro, that things are in need of a mez or a buff etc. I can disucss this specific idea in more detail if you're interested in considering it. This would be a big change to the way the main loop currently functions and thus a lot of work to remove as much delaying or while loops as possible.
This sounds like a major change, here's a
thread to discuss it before we make specific issues on the git board.
There's an absolutely insane amount of calls to /moveto and /stick in the macro. I've found that KA doesn't much care for StickHow and a large portion of the sticks don't use it. I would like to see (when loaded) KA use Nav for moving to a destination, or to a target because sometimes group placement doesn't allow for stick to handle getting to a target and I end up running into a wall trying to get to a mob in tight corners. I've used a pair of function, one of which checks for nav, and one which checks for stick during combat where if there is no line of sight and a path is available it will use nav, and otherwise if it has line of sight or nav doesn't have a valid nav location to use stick. I've had good luck with this experience and feed back from users suggests this works better overall. MQ2Nav is getting put in the spotlight a lot with the mesh library and updater and it's very common these days for a player to have a mesh available for navigating in pretty much any zone they are in. The movement issues are probably best displayed on the bard, but I've experienced a lot of weird behavior overall as far as movement goes and I feel that's a major part of my issue with the macro at this time.
Here's a
thread to discuss this further. If a movement revamp seems good, we can parcel it out to smaller issues for the git board.
I think taking a step back from adding features and addressing some of these issues would over all serve most helpful for the improvement to the macro.
PS. If you'd like me to help with one of the mentioned issues, or take it on specifically myself I'd be willing to create my own branch and look into trying to tackle it myself. Just tell which one.
Thank you, I'm sure ctaylor will take you upon that offer.
Inkie and I were just having a similar conversation to that loop statement that Chat made and it's a very good point. One of the things I mentioned was that neither plugins nor macros as written have an interrupt system, so making sure that you're not getting stuck in a loop or a sub is important to overall responsiveness of the macro. As Chat mentions, this is especially true in things like...aggro, heals, mez, etc. So, creating interrupts for these "trigger" actions or making your loop go fast enough that you are already back to the top if one of them happens is important.
Thank you everyone, again if I missed an issue you think is important, add it to the git board!