| 02:47.28 | ZorbaTHut | in general, I recommend against relying on "lots of event handlers = more time available" - that's the kind of thing I'll "fix" someday if people abuse it :P If you're having serious performance issues, set up an event queue. Make each event handler add an element to the queue, and make a coroutine that's called every Update.Begin to process a part of the queue |
| 02:49.45 | ZorbaTHut | that said, if your addon isn't creating framerate issues, it's probably something I won't be touching for a while |
| 02:52.28 | Ivnedar | so you won't like my rotating texture library then |
| 03:14.13 | *** join/#riftuidev odine (odine@cpe-74-77-168-188.buffalo.res.rr.com) |
| 04:07.19 | *** part/#riftuidev odine (odine@cpe-74-77-168-188.buffalo.res.rr.com) |
| 04:15.26 | Ivnedar | ooh, new discovery data file finally |
| 05:04.39 | *** join/#riftuidev Noshei (~quassel@c-67-161-146-244.hsd1.co.comcast.net) |
| 05:08.17 | *** join/#riftuidev Imhothar_ (miranda@ppp-93-104-169-71.dynamic.mnet-online.de) |
| 05:17.26 | *** join/#riftuidev bctrainers (~bc@unaffiliated/bctrainers) |
| 05:55.48 | *** join/#riftuidev Noshei (~quassel@c-67-161-146-244.hsd1.co.comcast.net) |
| 06:13.26 | *** join/#riftuidev bctrainers (~bc@unaffiliated/bctrainers) |
| 06:30.17 | *** join/#riftuidev Jon____ (~quassel@c-50-137-30-84.hsd1.wa.comcast.net) |
| 06:30.56 | *** join/#riftuidev Jon____ (~quassel@c-50-137-30-84.hsd1.wa.comcast.net) |
| 06:31.45 | *** part/#riftuidev Jon____ (~quassel@c-50-137-30-84.hsd1.wa.comcast.net) |
| 06:31.48 | *** join/#riftuidev Jon____ (~quassel@c-50-137-30-84.hsd1.wa.comcast.net) |
| 06:32.46 | *** join/#riftuidev gornutz (~quassel@c-50-137-30-84.hsd1.wa.comcast.net) |
| 11:06.40 | *** join/#riftuidev Jon___ (~quassel@c-50-137-30-84.hsd1.wa.comcast.net) |
| 11:18.24 | *** join/#riftuidev Noshei (~quassel@c-67-161-146-244.hsd1.co.comcast.net) |
| 13:55.25 | Ivnedar | Is a crafting api on the todo list? |
| 14:42.43 | *** join/#riftuidev g0urra (~g0urra@unaffiliated/gourra) |
| 15:21.56 | Baanano | does anyone knows if you get any event when somebody else modifies a guild storage identifier? |
| 16:05.12 | *** join/#riftuidev Torhal (~torhal@c-71-207-224-241.hsd1.al.comcast.net) |
| 18:58.23 | *** join/#riftuidev Imhothar (miranda@ppp-93-104-169-71.dynamic.mnet-online.de) |
| 19:09.05 | Imhothar | ZorbaTHut can I rely on Inspect.Item.Detail returning exactly the same before and after Event.Item.Slot? (excluding cooldownExpired and cooldownRemaining as they obviously depend on call time) |
| 19:11.09 | Imhothar | Mutable properties of course, like stack, bound, cooldownBegin/Duration etc |
| 19:12.09 | Imhothar | The documentation for Event.Item.Slot and Event.Item.Update are identical, maybe that could be improved a bit |
| 19:35.30 | *** join/#riftuidev Noshei (~quassel@c-67-161-146-244.hsd1.co.comcast.net) |
| 21:01.45 | *** join/#riftuidev odine (odine@cpe-74-77-168-188.buffalo.res.rr.com) |
| 21:02.19 | odine | Baanano: So did u end up starting up a guild calendar project? |
| 21:20.23 | Baanano | yes, i'm writing it |
| 21:21.24 | odine | im restarting my incarnation... i keep messing things up cuz i cant get the wow api out of my head... so im gonna be way behind ya now =P |
| 21:22.21 | odine | i wnated to go with efficieincy.. not having functions running when not needed ie: was i was trying to find a good solution to come with OnShow/OnHide for windows, but nothing efficient enough.. so i need to take a step back and rewrite a bunch of things now |
| 21:22.41 | Baanano | don't worry, right now it's for internal use on my guild, wouldn't like to maintain it |
| 21:22.45 | Imhothar | why not simply overwrite Setvisible? |
| 21:23.11 | odine | overwrite SetVisible() ? |
| 21:23.13 | Imhothar | the original SetVisible function is in the frame's metatable |
| 21:23.27 | odine | ohhhh wow i think i see where u going with that |
| 21:23.36 | odine | thats a damn good idea |
| 21:23.59 | odine | never thought about that, that could work wonders for my needs |
| 21:24.03 | odine | thanks a mil :) |
| 21:24.12 | Imhothar | you can just replace it by creating your own SetVisible function, call your own OnShow/OnHide and delegate frame:SetVisible(x) to getmetatable(self).__index.SetVisible(self, x) |
| 21:24.32 | odine | but i been going all out... tracking alts based on guld notes, i even went as far as to use the new attunement stuff so that when people signup it shows their ranks in PA etc etc |
| 21:25.01 | odine | simply amazing imho |
| 21:25.12 | odine | seriously thanks.. u might of just saved me from having to do a major bactrack :) |
| 21:25.22 | Imhothar | it won't work if the frame is shown/hidden if it's parent is shown/hidden, unless you overwrite SetVisible all the way up to the frame hierarchy |
| 21:25.30 | odine | right |
| 21:25.54 | Imhothar | np |
| 21:26.15 | odine | one more question.. currently with the api the way it is... is there anyway to have addon created frames "go away" with escape key like native windows do? or not possible yet? |
| 21:26.24 | Imhothar | no |
| 21:26.33 | odine | thought so |
| 21:26.43 | Imhothar | unless you track a native frame's Event.Loaded that gets hidden with esc |
| 21:26.55 | Imhothar | but hooking on native frame events is dangerous |
| 21:27.02 | odine | ya im not going there |
| 21:27.18 | Imhothar | cause you can have only one handler per frame, so it's very likely to fight with other addons for the event |
| 21:27.34 | odine | well with that said the event.Close() in libsimplewidgets takes care of my OnHide because the only way a window can be calosed is by pressing the close button in the window |
| 21:27.39 | Imhothar | unless I release my library for doing that hmmm |
| 21:27.50 | odine | but i might as well just do both onshow and onhide the way u suggested for effiencieny probably |
| 21:29.21 | odine | mkay. well eiother way i have some work to do.. thanks again! :) |
| 21:29.46 | Imhothar | if it helps |
| 21:38.36 | Imhothar | I use SetVisible on some RiftWindow instances which create their content the first time they're shown |
| 21:38.56 | Imhothar | cuts a bit time from /reloadui and who doesn't want that ;) |
| 21:51.41 | ZorbaTHut | imhothar, hmmmm. You might be able to rely on that. The tricky part is if there are two messages rolled into one - an "item removed from bag" and "item added to bag" message - in theory, things could have happened to the item between those messages |
| 21:51.50 | ZorbaTHut | but if the messages come quickly enough they'll be combined into a single message |
| 21:52.19 | Imhothar | What I really care about the most is whether I need to call IID after every Event.Item.Slot or not |
| 21:53.03 | Imhothar | because right now things go haywire when people use soul recall, suddenly getting performace kills and I'm trying to figre out why it happens only on soul recall, and only sometimes |
| 21:54.21 | Imhothar | in theory, the same events happen on every zone change but for some reason, not the same happens each time |
| 21:54.32 | Imhothar | or lets say on each loading screen |
| 21:57.43 | Imhothar | is it possible IID does things to the item cache and IID may take longer than usual? |
| 21:57.51 | Imhothar | I mean loading screens |
| 21:59.53 | Baanano | imho, it happens too when using porticulums, resurrecting... every time the loading screen is shown |
| 22:01.22 | Imhothar | ah hell |
| 22:02.51 | Imhothar | but not every time? |
| 22:03.00 | Baanano | starts happening after 4~5 hours online, then almost every time the loading screen is shown |
| 22:03.43 | Baanano | not every time, was playing conquest and sometimes it was when resurrecting, others when taking a portal, others both times... |
| 22:03.51 | Imhothar | do you like ruining my evenings? |
| 22:04.45 | Baanano | i wondered why it had to IIDetail items in my bank though :P |
| 22:06.04 | Imhothar | because Rift tells me to |
| 22:06.21 | Imhothar | loading screens trigger IID with ALL your item |
| 22:06.22 | Imhothar | s |
| 22:06.29 | Imhothar | argh Event.Item.Slot |
| 22:06.34 | Imhothar | not IID |
| 22:06.40 | Imhothar | well it leads to IID |
| 22:06.54 | Imhothar | that's why I need to stop calling it all the time and figure out whether I need to or not |
| 22:09.01 | Imhothar | why the perf kills only start happening after 4h is another thing to investigate |
| 22:09.42 | Baanano | maybe the item cache got too big on that mark, or maybe that was the first time i opened my bank or guild bank or whatever |
| 22:09.59 | ZorbaTHut | I can look into it and see if I can provide any stronger guarantees. That said, this may be another "amortize over multiple frames" deal. |
| 22:10.12 | ZorbaTHut | Why kills would start happening after 4h is, however, a total mystery to me. |
| 22:10.25 | Imhothar | Zorba, it's not that simple to queue the Event.Item.Slot over multiple frames |
| 22:10.47 | Imhothar | by the time an item gets processed it may have changed already |
| 22:10.51 | Imhothar | for example |
| 22:11.14 | Imhothar | not sure if it's a problem though |
| 22:11.40 | ZorbaTHut | well, in theory, it doesn't matter - you don't need to track every change, you just need to approach real-time as quickly as possible |
| 22:11.49 | Imhothar | then I'd need a queue, as a table doesn't keep chronoligal order and an array is way too inefficient for frequent insert/delete |
| 22:12.35 | Imhothar | yeh, so everytime I'd get a Event.Item.Slot/Update I'd need to scan through the queue and remove multiple occurences of the same item |
| 22:12.40 | Imhothar | that doesn't sound efficient |
| 22:12.46 | ZorbaTHut | Well, first, the queue is probably small |
| 22:13.02 | Imhothar | except on loading screens |
| 22:13.05 | Imhothar | where it explodes |
| 22:13.55 | ZorbaTHut | second, there's no real reason to *remove* occurences. Keep two maps of checkpoint numbers, from item ID to item "revision". The first is "game state", the second is "our state". When you get an update message, increment game state. When you process an element in the queue, check to see if "game state" equals "our state". If it does, don't do anything. Otherwise, update normally, then set "our state" to "game state". |
| 22:14.19 | ZorbaTHut | The end result of this is that, sure, maybe you have six "item 1234 is updated" message in the queue. The first will actually update the item, the remaining five will say "oh I guess we're already updated, move on" |
| 22:14.33 | ZorbaTHut | if the item changes again, then the next update message in the queue will simply refresh it. |
| 22:14.58 | Baanano | is it important to scan in a cronological order? you could have the queue entries be { [itemID] = true } and just use next until it's empty |
| 22:15.48 | Imhothar | that would work well for Event.Item.Update, for Event.Item.Slot I also have to track the slot and move it around properly. I think I may apready have a itemid to slot map |
| 22:16.19 | Imhothar | hmm |
| 22:16.37 | ZorbaTHut | so, hmm, I guess here is what I would do in your situation |
| 22:16.57 | Imhothar | go home? |
| 22:17.17 | ZorbaTHut | I'd assume that Event.Item.Slot won't change the item data for now, but for a version or two, I'd throw in an assert to doublecheck it |
| 22:17.25 | ZorbaTHut | I don't *think* it can |
| 22:20.21 | Imhothar | Baanano, I need definitely to track the chronoligal order for slot assignment. If the item leaves the player's bags without appearing in a different slot in the same event, it has left the player's reach. Should it come back the next event it may have changed |
| 22:20.50 | Imhothar | and as I'm typing that I'm getting nightmares |
| 22:21.39 | Imhothar | why does it sound like a total overkill of management code to get past the damn watchdog... |
| 22:22.34 | ZorbaTHut | keep in mind that we frequently end up doing similar stuff on our end to keep performance good. :P |
| 22:22.45 | Imhothar | need to give this more thought. Would be a cakewalk in C++, but Lua makes it a bit more difficult |
| 23:46.34 | Baanano | hm, I'm comparing os.time against Inspect.Time.Server and they only have a difference of 10 seconds, but according to the clock below the minimap they should be 1 hour apart |
| 23:47.07 | Imhothar | timezone |
| 23:47.10 | Imhothar | ? |
| 23:48.07 | Baanano | me: CET, server: GMT (at least according to the minimap clock) |
| 23:48.39 | Imhothar | CET is UTC+1 |
| 23:48.54 | Imhothar | GMT is UTC |
| 23:50.11 | Baanano | yeah, i expected a difference of ~3600, but it's only ~10 |
| 23:50.49 | Imhothar | they both have the same timestamp |
| 23:50.55 | Imhothar | timezones only change how they are printer |
| 23:51.02 | Imhothar | printed |
| 23:51.28 | Baanano | oh didn't know, so I don't have to do any conversion? os.date will take care of it? |
| 23:51.35 | Imhothar | time() always returns the same, no matter where you are. the time zone only plays a role when you read/write the date as string |
| 23:52.27 | Imhothar | what exactly time() returns depends on the OS, but it's usualy the unix timestamp, which is always in UTC |
| 23:54.44 | Imhothar | hte timestamp itself doesn't contain any timezone information, that's only required when pesky humans are involved |
| 23:57.10 | Baanano | so, if i've understood correctly, when i generate a timestamp, the os.date of other players will take care of adjusting timezones |
| 23:58.14 | Imhothar | aye |