• 0

    posted a message on Cant commit to repository after merging to Twitch account

    I can't commit all the sudden on any repo for any game, though I did a WildStar AddOn update a few days go.

     

     

     

     

    Posted in: General Chat
  • 0

    posted a message on New dev tool - Addon Studio for World of Warcraft
    I'm actually the one who did the port of AddOn Studio to 2010 in sort of a rather heritic type move as usual, and my version isnt affiliated with the one on codeplex at all.

    Its not baked by far, though a lot has been fixed. Ive worked on game engines and game production tools before. In practice there are usually a mix of visual style tools and do-it-by hand, and a huge number of build and process tools.

    There will probalby be no Lua Studio. I was to my suprise contacted by Daniel Fernadez today via e-mail, who is one of the project managers at MS and the reason that tool was created.

    AddOn Studio is not really for the faint of heart atm. A noob would benifit by the working shell being generated to start to understand what is what, benifit form teh auto wow detection and ability to in a few click see their addon in wow running, and get a chance to play wiht a few things but after that gets hard. There are a bunch of things if you are very familiar with AddOn dev and distribution, like workign integrated SSC, and ability to load the toolkit as a web project to explore the scripts and frames in a lua and wow aware way, and for what its worth and as much as ti works, see your UI without having to play deploy reload as much, and a ton of other things. But it needs a great deal of work still.

    I have seen real world examples in real places making real games, and do belive that visual tools are possible for game production, though its nto always the first priority. I do think it has its place, and at some point be the eventual future.

    More later... :)

    If you wish I'd like to start a AddOn Studio project thread, and if it pleases the powers that be, would like to ask about the whole issue of curse pages for binary projects again, that arnt necessariliy AddOns.
    Posted in: Frameworks
  • 0

    posted a message on Raid Tracker offical thread
    there thats my wall of text for the next year or so. :)
    Posted in: Raid AddOns
  • 0

    posted a message on Raid Tracker offical thread
    Reading over all this again, a few more things to add as the original blabbering was assumign the reader already understood the basic mechanics... (On which im willing to be wrong or take criticsm on my assumptions not being correct.) :)

    1. OnUpdate type handlers operate normally only if the frame (and its parents) are visible. However if you create a top level frame with no graphics, you have what i was calling a "hidden" frame, which is one thats always "visible" but not drawing anyting. In that case, its OnUpdate will get called once per frame. This is also the reason mods have to actually make a seperate frame to use OnUpdate as a background timer, to run code that needs to be run occasionally. In LUA in this WoW environment, there is no other easy way to run code in the background, so this is how its done. Your only code paths are at the mercy of being a part of an event handler, and from which if you dont return, the game will cease to continue its per frame duties and the world will end, no pun intended.

    2. The "mainframe" OnEvent handlers are a special case where you will recieve events on a frame thats visible (or not), based on events you register for, like ON VARIABLES LOADED and so on. Most applications only use one handler for this thats attached to their main application frame even if its just a faux frame for this purpose, which is what I was calling "mainframe" handler. This "mainfram" handler could run actually more than once per frame, each time geting passed a differnt event id, so its notnecessarily less immune to performance issues than the "scarry" hidden frame OnUpdate. And for Ace derived ones, at least it used to work this way, the actual code getting called begins in Ace, and thus is attributed to Ace by the profiler. Ace also creates, or used to, its own "hidden" OnUpdate handler as well with its own "hidden" frame, which is created automatically by Ace when the lib starts up. That part im pretty sure about but i havnt looked at Ace3 in a while.

    3. Other specific event handlers like OnMouseWheel(self/frame,delta) will obviously only get called when say the mouse wheel occurs and it woudl make sense this could only happen if the frame was actually visible and rendering something as to have actual "focus" to take input events. So they dont normally fire all the time on their own, unlike what im calling "mainframe" handler or the "hidden" frame OnUpdate handlers would.

    4. Yet another class of event are the general OnEvent handlers, where for a frame you are creating a handler to look at all the "normal" UI events for the frame and handle or dispatch them yourself. You could look for the mouse wheel event in the regular OnEvent handler and call your OnMouseWheel handler or simply handle the event right in the OnEvent. OnEvent will fire for every "UI" type event that is in the scope of that frame, of the "specific event handler types" as noted in 3. above.

    So the handlers in 1. and 2. are the usual points of failure as far as hurting game performance (other then more general issues like global polution and memory management, etc..) as both can run more or less without provocation and for every mod and every render frame... or more. Whats curious about the test is that it looks like on my setup with my Cata version and my choice and breakout of libs, that the profiler is showing the underlying dispatch mechanics as part of the count, which I image is virtually the same when you get right down to it between the "live" OnUpdate handlers and the "live" mainframe OnEvent handlers. Its as though its determining the target code Add-On and then couting too corse of a start and stop point, and somehow using that setup cost amoritized across the one or two places actually getting called, and/or counting it more than once.

    For refernence ChocBar would get time say every 5 seconds or so, but qTips and Broker_CPU burned the most time, far more then the relativly quiet Karma and Ace. CPU was doign like supposedly 0.100+%, and qTip like 0.054% which was like 100ms/s according to the profiler, vs like the 0.007% per idle type 1. and 2. handler in Karma and Ace. So the numbers for the idle handlers were very very small, even with the profiler on, jsu to keep this in persepctive. And I dont think CPU is that inefficient overall. It coudl be cleaned up some, but relative to alot of other apps is small.

    Again... 60fps is ~15ms (really a bit less) per frame. I think the author of CPU, who im sure was making a very labor intensive and honest effort to be efficient, would be sadended to be told his code is costing over 6 fps jst to show profiler numbers. And I really dotn think thats the case.

    Also, there are a few things that are not counted in the profiler, that apps can do to hurt performance. And what im getting at in this case is render setup vs render time. When your mod runs, nothing is being changed on the screen right then. You are simply telling WoW what you would like next time it renders a scene and the UI. Also once the UI lua is all done, for that frame, there is no such thing as it calling your mod during render time, so the Lua code runs at a specific point during the process and thats it. This is also why its so important to get your business done and get out of the way and jsut whats necessary, which poor Ace guys have been tryign to champion this whole time. :) When your mod runs and manipulates a visible frame and all of its visible children, you are only being profiled for what i'll call your "render config time", but not its impact at render time during the rendering of the next frame. The profiler is only showing the cost of handling the events and plus profiler overhead and other stuff, and the cost of your changes to the "configuration" of the UI. You are not being charged for the cost of rendering your UI frames in the last or next frame. You could in theory with very little code and lua time, create UI elements that are a fortune to setup the pipe and render for. So be careful. WoW is very good at dealing with what is a fairly heavy UI model and all of its moving parts, but some things cant be helped.

    I hope this might help anyone trying to do profiling and help them measure whats really important, and what to discard given the current state of things with WoW mods. :)
    Posted in: Raid AddOns
  • 0

    posted a message on Raid Tracker offical thread
    K last thing about this...

    I found two other OnUpdate events, one using the blizzard UI idiom for handling item tool tip notification and updates.

    Something like:

    function LibKarmaUI:OnUpdate( frame )
    if frame.hasItem and GameTooltip:IsOwned(frame) then
    ....
    end
    end

    Which allows the tooltip to update itself after the server callback gets the iteminfo into the clients cache, and all that other complexity that makes blizzard item tooltips work like they do.


    And a second very similar idiom on OnUpdate belonging to the Minimap App Icon used if there is no broker display or FuBar like thing around. Somethign like:

    OnUpdate...
    if self._ismoving then
    Recalc minimap pos...
    end

    So if you try to replicate the test, you will see "aparent" movment on RT itself at times, and sometimes not.
    Posted in: Raid AddOns
  • 0

    posted a message on Raid Tracker offical thread
    Ok, afer a lot of testing and breaking packages/libs out, here is what i think it going on.

    Grand summary first... its the built-in profiler.

    The actual culprit if i turn my event handerlers off, all of them, is Ace3.

    Before i did nolib for everything, my embeded Ace3 (which ever part of ace3 is catching Ace3 events for everyone, the "got my own frame and handler" one) was getting picked for some reason over ChocBar's, and it was pulling at minimum 0.007%. Broken out, where Ace3 is in its own lib loading under its own TOC, it did the same thing, but was more obvious in the CPU display. Then i turned on my event catcher for my main frame, which pulled at minimum 0.007%. So far the odd part is that one is handling specific events and suposedly only getign called when an event fires (the RT mainframe) and the other (the Ace3 one) is getting called every frame, but they got the same displayed result, and the same "aparent" cost. Then I turned on my own hidden frame handler and it got... 0.007% for "apparent" cost too. I didnt touch Ace3, but i basically did a "if true then return end" type thing at the top of each handler for my "hidden" and "mainframe" handlers and the result was the same, more or less 0.007% on this computer as it sits atm across all of them.

    I saw sometimes where the RT side hidden frame was beating hte Ace3 one by say 0.003-0.005%, at like ~0.004% while Ace3 was sititng at closer to 0.009% or so. But in general it looks like "aparent" handler cost is around 0.007%. So if you hit garbage collect jsut after everting 'init-ed', and jsut watched, you would at first see only two things besides Borker_CPU and qtip moving... the KarmaLib and AceLib, which were the ones handling the actual events for everyone, where Karma dealign with two handlers was 2:1 or more lower than Ace3 dealign with one. After a while ace would settle down (or the profiler would not amitorize the same) and it would float 2:1 the other direction, where it was like Karma 0.014% and Ace 0.007% and hold, until the profilers amitorization wiggle again. But i belive its an 0.007% "aparent" cost each instance in general on this machine.

    So when you spun up RT, and it was actually optionally using Ace3 and getting to be the Ace3 handler home, plus the Karma hidden frame, and the Karma mainframe proxy, plus whatever you had to measure and display it all, you could have someting that looked like it was floating around 0.014% to 0.036% with everyting else looking like it was dead. And RT effectvely processig no events except the 0.5 sec interval timer sync by the karma lib (which watching over course of 10 mins, the actual event code firing had 0 impact on the numbers).

    So... I belive at this point a few things.

    1. We are seeing primarily a profiler overhead or possibly broken amoritization math, and not real cost. We know that the event path is the point where it runs the events and it decides who's fault it is, and i don't belive that each handler is actually cosing 0.007% or like 8-23ms per second. Since this test only had 3 effective handlers of those types to play with, and in the wild there are far far more. I dont think that the displayed number is even close to the reality.

    2. To go wiht that and in defense of..., I dont think Ace3 is really burning 0.007-0.014% (10-14ish ms per second) itself on my computer by just having a handler operating per frame, thats in lua and i that i know is simply gettign called just before or after my per frame handler, and that i know that these two are jsut two of many hidden per frame lua events being processed. And, that i know is only getting called about every 15 to 30ms at worst.

    3. Its hard to show raw numbers for this, but I believe that when its runningn with the profiler off, there is near 0 cost at rest for Ace, RT, and others, so long as minimal amount is beign done during event handling.

    So, I think its all as good as can be.
    Posted in: Raid AddOns
  • 0

    posted a message on Raid Tracker offical thread
    Ok so im jsut too sleepy. The ms is total time since restart. Atm on this cheap notbook, (lenovo g555 dual core athlon2/ 64-bit windows7 ult) wiht wow in a 800x600 window sititng in darnassus, ive got:
    Broker_CPU  ~870ms  0.054% cpu
    RT              ~480ms  0.026% 
    LibQTip        ~380ms  0.022%
    ChocBar        ~26ms  0.0%
    
    Posted in: Raid AddOns
  • 0

    posted a message on Raid Tracker offical thread
    Ok... I jsut looked at this and I dunno... lol

    I used CPU_Broker with chocolate bar and qtip, (i still miss fubar and perf fu) as CPU_B looks liek the only currently maintained perf viewer. Adding qtip was the only way i could get it to display CPU time, which may be by design. I had just RT, Choc (no Choc options addon), CPU, and qtip loaded. I did not break out the libs, left them in place on everything.

    What I saw was a bit of odd measurement or display.

    The CPU time was in (ms), which I imagine is milliseconds. Right now it reads 24 ms for choc and 22 ms for RT, which im guessing is intended to be per tick of the update, which looks like every second jsut staring at it. I'm kind of seriously doubting that either take as much as 23ms every second, even giving some room for measurment overhead. The for some perspective the entirety of the whole engine must do everyting in like ~15ms per frame to get 60 frames per second. The code thats active is probably like 10 lines of simple LUA if statements total, plus a few local vars geting set from already processed data, just for convenence (like selecting first 6 vars off of the ...). I chopped off the event processing making it return immediately on any events, and the results were about the same.

    I think the display of the CPU addon data isnt baked in this version.

    I'll look at more in a min.
    Posted in: Raid AddOns
  • 0

    posted a message on Raid Tracker offical thread
    Quote from Zidomo
    Still looking for a permanent replacement for the ICC-impaired HeadCount & the display-impaired NRT, decided to start testing Raid Tracker a couple months ago.

    As normally do with mods to be used on my raiding characters, started testing on a low level alt. With v2.2.60, the mod used between 0.500-0.600 CPU/second when the character was idle & solo (tested alone, all libraries disembedded & "most recent" versions from the WowAce SVN/gits). Which is not good at all; didn't test it any further.

    Still looking, decided to give the current v2.2.62 a try. On the alt, the idle CPU usage has dropped to 0.130 to 0.140 CPU/second. This was after disabling the "solo" (& party)
    ...(snip)...
    why any CPU at all when solo and/or idle? Neither NRT nor HeadCount use any CPU on idle and its unexpected behavior for a mod that should only be active in raids.


    Ill sort of summarize my response from to the Ticket you added for this here, just for completness. There are only three things in RT that will burn time if you aren't directly interacting with it.

    1. There are various handlers for events registered will be called each frame, unless they are unregistered laster at some point. because most events are fairly course in what they cover there are really very few that i could "unregister" and still have everything work correctly. Simply examining a few events is fairly inexpensive to the point it relaly shouldnt show on the timers at all.

    2. there is a background timer on a separate hidden frame to keep the current "RT uniform time" in sync, and monitor things like when a user goes to another "shared" instance server which happens to be in another time zone form your "realm server" timezone which solves lots of issues. This will handle the event only once every half second or so, or proably for most people thats once every 30-60 frames. What is does is it checks a few "class" vars, and calls a few client only functions, and asks like "what's the server time" and "whats the client time". Its very very very fast. This would probalby never show up on perf meter.

    3. This one, the one that probalby showing up on the perf meter, isnt really an RT thing. It has to do with the Common Libs that RT is carrying in its package. When one of the libs burns time that RT is sharing, the time is attributed to RT since the profiler doent knwo the difference between my code and the libs im carrying. If my libs are the newest, or I happen to be the first app loaded that carries a lib that commonly used, then that copy of the lib wil be used, as it per design for LibStub which is an Ace derrived lib. Some of the perf meters are pretty good at following the idea of shared libs, but generally it shows on my CPU time, even if im not doing it.

    I'll go make sure all my event short circuits are still in good shape reguardless. And I apreciate your looking into all this. :)
    Posted in: Raid AddOns
  • 0

    posted a message on Raid Tracker offical thread
    I'll look into it. :)

    Theres not really anyting about RT thats not "ICC compatible".... :)
    Posted in: Raid AddOns
  • 0

    posted a message on Raid Tracker offical thread
    Quote from Pseudopath
    Copied from my comment on Curse :

    Also I was wondering if you would entertain a possibly work-intensive request; My guild uses a Loot Council and a basic table of players/raids/loots to give a VERY basic ratio of loot distribution. Would you be able to add a guild player table that gives them a value determined by guild raid attended, rank (ie 1=raider, 2=trial), and loots (ratio number = raids-rank-loots)? If not any advice would be appreciated, I'm not anywhere near an expert with XML/LUA? Thanks again.

    Thanks,
    - Pseudopath.


    Sure. Is this something you wold like done as an alternative export? Someting you want shown in the ui? Woudl you want a text format type file export that jsut gave you the list to be viewed in wordpad? Let me know.
    Posted in: Raid AddOns
  • 0

    posted a message on Raid Tracker offical thread
    Quote from electronicpunk
    Any update for this great mod coming?

    The frame looks a little odd for me in 3.2 and also it didn't seem to record any loot last night for us in the coliseum/ulduar.


    Thats all been fixed. RT borrows the Quest Log UI frame, which changed with 3.2 to a dual panel layout.
    Posted in: Raid AddOns
  • 0

    posted a message on Raid Tracker offical thread
    thanks ill look
    Posted in: Raid AddOns
  • 0

    posted a message on Raid Tracker offical thread
    It's been updated. Enjoy :)
    Posted in: Raid AddOns
  • 0

    posted a message on Raid Tracker offical thread
    Titan/LDB added in 2.2.8 :)
    Posted in: Raid AddOns
  • To post a comment, please or register a new account.