Z-Perl 2
Thoose who follow my GitHUB page (so basically noone), may noticed i started working something new. (not again!) I know right, i get bored so easily.
So this is gonna be a full rewrite of Z-Perl, without the unnecessary old crap in the code, and hopefully with no more xml. What is worth mentioning is that the addon will use a very unique scaling method bypassing the terribad Blizzard one, which will allow almost pixel perfect scaling even on very small/big scale numbers, while the small textures on the frame won't get obliterated (like edges, borders and background positions): https://www.youtube.com/watch?v=Nh77TEZBj6A The player frame is almost fully functional but there are no options nor saved variables to handle the size/scale/position changes, but you can download it just to play with it, from here: https://github.com/Resike/Z-Perl2 |
New functions:
- Incoming heals and absorb indicators. - Cast and channel bars. - Elite indicator texture. - Class and leader icons. - Buff/Debuff frames. - Pet/Vehilce frame. Mage POV: https://www.youtube.com/watch?v=9EzZ_nUwUV0 Priest POV: https://www.youtube.com/watch?v=z-TizIuINM4 |
That looks great, especially the scaling. How long before you have a target frame? I wouldn't mind trying them out.
|
Quote:
|
Quick update about the raid frames, here is a fully functional base raid frame mod in a 40 man raid combat at 60fps, and it's using around 0,05% cpu to update and draw frames in real time, while it's also handing the player and the pet frame:
|
I've been using some form of Perl since ... well, since I got it with Cosmos, I think? Is that where I got it the first time? I think that one was Nymbia's version. After playing WoW with it for so long, it's pretty much impossible for me to change to something else; I've tried at least two separate times. So, I had just accepted the performance issues with X-Perl, which were, as I'm sure you remember, not insignificant.
So, for the sake of my sanity and of my framerate during raids, thanks for keeping the project going. :D ----------------- I was just catching up on the development forums and noticed your thread here. Your isDeveloper function and your "encrypted" battletag are pretty funny. I assume that's just to prevent it from getting scraped from GitHub? Dat MakeScaleable function. Yikes. Do you think it would be possible to do something like this:
Or, if that would be viable and if you wanted to be super sneaky, you could create a scaling frames pool and never run the create code more than either once if the user doesn't ever resize more than one frame at a time or (assuming it will be possible to resize frames concurrently) n times, where n is the total number of frames (frame classes?) available to be resized concurrently. I say "frame classes" because I'm not sure how much sense it would make to be able to make raid27 a different size and shape than raid12 (or party2target and party4target and so on). Well, starred and watched. It's going to be arguably way more fun, for me, to watch you build some unit frames from the ground up than to (try to) build them myself :). |
Quote:
My battletag is encrypted to prevent parser functions to catch it by any way. I'm not sure if you are familiar with this project but it's handling the scaling method just the way you described it. It can also scale multiple/linked frames at once. However the function is even more kinky there, since that one also handling Texture and FontString scaling perfectly. MoveAnything 2: http://www.wowinterface.com/forums/s...ad.php?t=49385 In action: https://www.youtube.com/watch?v=FZvb5ae3c1c In Z-Perl 2 i use a modified version of the scaling function from MoveAnything 2, because i wanted to scale the border of the frames with a different scale-multiplier, since borders look really stupid on high and low scales. Thats why that MakeScaleable function is a monster. (Also because it's not really optimized yet.) |
Ha! It's funny: software engineering is one of the few places where I'm not only okay with someone suggesting to me what I'm already doing, but am often quite encouraged by it. :)
|
Resike are you decoupling the unit functions from the layout? A templating system would be amazing. I want such a unit framework too. Just not in Perl style.
|
Quote:
I'm not really familiar how does this OUF like layout templates works, since i was a Perl user for life, but i can look into it. |
Well lets use oUF health element as an example.
https://github.com/haste/oUF/blob/ma...nts/health.lua It provides the events needed to trigger health value updates. Yes it does some coloring by default too which should be kept out of the update function but haste decided to use it that way. Better would be an attribute switch. Example. The event handler triggers for unit has disconnected, so it sets an attribute on the health element to true/false. One can use PostEvent function in the template to give the healthbar the desired color. Basically all the health elment should provide is the event handler for health related events giving a template engine the option to hook the event handler. |
This may seem a bit off topic but since I looked into your code when I was working on changing what I used to unload blizzard's raid frames I was wondering if you were giving thought to how you are doing it going forward?
It looks like they are adding more functions to better load and unload compact raid frames but I don't know if they are finally going to start reworking the horrendous coding that taints if you look at it funny. What I have done with great success is to just disable the blizzard addons that handle compact raid frames, profile, and the raid frame manager completely. It adds a step to the user of requiring a reload to disable them or reenable them but it eliminates just hiding the framework of this buggy mess and instead just removes it completely. Granted this prevents party frames from being used as compact raid frames but in cases of a complete unit frame package like z-perl you don't even want party frames. The additional benefit is it also disables the raid frame interface options from blizzard. By disabling these two addons: DisableAddOn("Blizzard_CUFProfiles") DisableAddOn("Blizzard_CompactRaidFrames") you remove them from the equation. One huge benefit I have noticed is the raid frames in my addons are much more responsive and i haven't got a single compact raid frame taint error since doing this. Just a thought. |
That is what I am doing with rRaidManager aswell. Gets rid of a lot of troubles.
|
Quote:
|
Yes it does completely disable and therefore removes that manager. It means either users have to use keybinds/commands to place markers or if you added it in you could have a flyout or otherwise attached frame/buttons that allows for fast marker placement and ready/role check buttons.
I think the benefits outweigh the loss of the built in raid manager frame. I personally use the addon FlaresThatWork but something like that could easily be built in |
That is the point why adding a simple raid manager is what you want. Instead of all the overhead. You can take a look at rRaidManager if you want. It does just that.
|
Quote:
|
Quote:
|
...
https://github.com/zorker/rothui/blo.../core.lua#L195 Not even sure if my slide-out window needs to be secure or only the macro buttons have to use the SecureActionButton template. Anyway. It works just fine in combat. |
Quote:
|
All times are GMT -6. The time now is 03:23 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI