| 00:03.44 | seebs | Oh, weird. |
| 00:03.58 | seebs | deflated, eof, bytes_in, bytes_out = deflate(string, "finish") |
| 00:04.03 | seebs | bytes_out != #deflated |
| 00:04.57 | seebs | Or I'm doing something wrong. But that's actually one of the listed tests for lua-zlib. |
| 00:05.05 | seebs | ok(#deflated == bout, "bytes out is the same size as deflated string length") |
| 00:05.47 | Imhothar | # doesn't count null terminator |
| 00:06.03 | Imhothar | actually Lua stirngs aren't null terminated |
| 00:06.19 | Imhothar | oh wait |
| 00:06.27 | seebs | It's not that. Actually, it looks like #deflated == bytes_out, but somewhere ELSE I am getting a thing. |
| 00:06.50 | seebs | Ahh, right. Because I have another tier of compression/checksumming I'd forgotten about. |
| 00:06.56 | Imhothar | ah yes I mistook deflated for the input |
| 00:07.19 | seebs | So my real problem is just that I'm comparing the wrong data; I hand a compressed string to my library, which then Does Stuff that may produce a longer string. |
| 00:15.18 | seebs | Hmm. |
| 00:15.54 | seebs | That one's really annoying, though, because the "Incorrect Function Usage" message doesn't actually tell you what's wrong. |
| 00:21.50 | seebs | Gah. |
| 00:22.00 | seebs | Okay, so. command.storage.set, with #data = 2044, throws an exception. |
| 00:22.12 | seebs | But 2044 isn't a number you can derive from anything observable! |
| 00:22.27 | seebs | You just sort of have to guess at how close you can come, and if you're sort of close, maybe that's it, or maybe not. |
| 00:22.55 | Imhothar | can't you query storage for usage and free space? |
| 00:23.47 | Imhothar | Utility.Storage.Limits + Inspect.Storage.Used? |
| 00:24.00 | Imhothar | and Utility.Storage.Size |
| 00:24.21 | seebs | Has nothing to do with free space. |
| 00:24.43 | seebs | If you have empty player storage, and try to store 2049 bytes, obviously you get an exception because the API *knows* that 2049 bytes cannot be stored. |
| 00:24.56 | seebs | If you have mostly-full storage and try to store 1k, you don't get an exception, but you do get an error callback. |
| 00:25.11 | seebs | But if you have empty player storage, and try to store 2044 bytes, you get an exception for incorrect function usage. |
| 00:25.20 | seebs | Because *in fact*, the amount of storage needed is probably higher than that. |
| 00:25.20 | Imhothar | keep in mind that the identifier is stored too |
| 00:25.34 | Imhothar | and afaik it's padded to 64 bytes |
| 00:25.43 | Imhothar | that's why there is Utility.Storage.Size |
| 00:26.58 | seebs | hmm. |
| 00:27.03 | seebs | Well, that's interesting. |
| 00:27.27 | seebs | It doesn't seem to be padded. I can store 2,034 bytes of data plus the identifier "merisioux_data". |
| 00:27.32 | seebs | Oh, I see. The total is probably what's padded. |
| 00:28.20 | Imhothar | not sure what is padded, but when developing StorageViewer I noticed the minimum message size was always 64 |
| 00:29.18 | seebs | What I'm guessing is that the identifier+data are then, together, padded to 64. |
| 00:29.39 | seebs | But! The interesting thing is, 14-byte identifier + 2034 bytes of data. Which means that wherever the size of the identifier is stored, it's not in the data budget. |
| 00:30.08 | Imhothar | the API doesn't say the identigier is binary-safe |
| 00:30.14 | Imhothar | maybe it's null terminated |
| 00:30.16 | Ivnedar | 15 byte identifier + 2034 data? |
| 00:30.38 | Ivnedar | since 14 + 2034 = 2048 |
| 00:30.39 | Imhothar | dunno, could be stored in a indes structure |
| 00:30.49 | Imhothar | s/index/index/ |
| 00:30.53 | Imhothar | argh |
| 00:31.25 | seebs | Yeah. Dunno exactly. Anyway, I am now pcalling a little more and added more callback hooks for detecting failures both immediate and postponed. |
| 00:31.35 | Imhothar | have you checked if the free size increases by more than what Utility.Storage.Size reports? |
| 00:31.54 | Imhothar | s/increases/decreases/ |
| 00:32.30 | seebs | I haven't. But it does seem that if I check Utility.Storage.Size before calling Command.Storage.Set, I can no longer trigger the exceptions. |
| 00:32.54 | Imhothar | better still keep the pcall in there for race conditions |
| 00:33.07 | Imhothar | at least for guild storage |
| 00:33.10 | seebs | Yup. |
| 00:33.21 | seebs | Not gonna take that out, I don't trust the call not to develop new exceptions later. |
| 00:50.11 | Imhothar | it's too bad the Rift API isn't more predictable when it comes to errors like that |
| 00:50.39 | Imhothar | especially if you got a callback |
| 00:52.49 | Imhothar | the fact error conditions aren't usually documented is not a big help either :( |
| 00:53.23 | Ivnedar | lol, one of the units here have renamed themselves from "Databases/Development" to "D&D" |
| 00:53.32 | Ivnedar | so my wife is now in the "D&D Special Projects" team :D |
| 00:53.45 | Imhothar | and she's a happy woman from now on |
| 01:02.46 | *** join/#riftuidev Imhothar1 (~Adium@ppp-93-104-191-112.dynamic.mnet-online.de) |
| 02:09.10 | ZorbaTHut | yeah, I'm not happy with how the error conditions work, to be honest |
| 02:09.59 | ZorbaTHut | I wanted errors to be loud - which they are - but I think they're *too* loud. if I was doing this again I think I'd rig everything through some kind of error-callback system. functions will never throw lua errors, they'll just call whatever your addon error handler is set to |
| 02:10.10 | ZorbaTHut | (which would default to "throw lua error", natch :V) |
| 02:10.29 | ZorbaTHut | too late now to change it, though |
| 02:11.56 | ZorbaTHut | also I really should have rigged up descriptive error messages earlier. the infrastructure's actually in place, just gotta go write a ton of error messages |
| 03:19.55 | Amadeus- | in case you missed it after all of the scroll: |
| 03:19.57 | Amadeus- | ZorbaTHut, why does zoning (or loading into the game) take so long (and basically stop) when viewing another window? In other words, if I select my charater and then alt-tab here to IRC ..it takes FOREVER for the toon to zone in. However, if I alt-tab back over, it goes quickly. |
| 03:20.42 | Ivnedar | zoning doesn't complete if the game is alt-tabbed out |
| 03:20.50 | Ivnedar | that's how one of the conquest exploits works |
| 03:20.59 | Amadeus- | really? |
| 03:21.05 | Ivnedar | yeah |
| 03:21.20 | Ivnedar | if you alt tab out while conquest is loading, you're not really in the zone, but you get all zone rewards |
| 03:21.26 | Ivnedar | you also don't get ported out at the end of the match |
| 03:21.34 | Ivnedar | so you can stay in there as long as your connection to the server is up |
| 03:21.42 | Amadeus- | I never knew ..hehe |
| 03:21.45 | Ivnedar | and get rewards for every match |
| 03:22.07 | Ivnedar | afk kick doesn't trigger either since you've never joined the game fully |
| 03:22.41 | Amadeus- | seems like being able to zone while alt-tabbed would be something ZorbaTHut would be able to fix with his coding chops :) |
| 03:30.10 | seebs | Huh. |
| 03:30.34 | seebs | *thinks* What if we used named exception types and set up a handler that would let you catch specific exceptions for a block of code? |
| 03:30.40 | seebs | I suppose that's probably more trouble than it's worth. |
| 03:31.46 | ZorbaTHut | amadeus, I actually don't know. Sounds like a bug. :V |
| 03:32.23 | ZorbaTHut | seebs, lua's exception system is unfortunately not all that language-supported. there's lots of ways to build an exception system within lua, but they all end up somewhat syntactically gnarly |
| 03:32.27 | Ivnedar | I assume it was put in the "too hard" basket |
| 03:32.35 | Ivnedar | It's been reported for years |
| 03:32.59 | ZorbaTHut | though note that in a sense, that's what it already does - if you want to catch pcall's you can. and I believe you can replace the system error handler entirely if you so choose |
| 03:33.18 | ZorbaTHut | ivnedar, I suspect it's at some intersection of "too hard" and "doesn't matter" |
| 03:33.24 | Ivnedar | yeah |
| 03:33.32 | Ivnedar | if people want to afk in conquest, good for them :) |
| 03:33.38 | ZorbaTHut | it definitely doesn't happen if you're in windowed mode, and I suspect it doesn't happen in fullscreen windowed mode |
| 03:33.53 | Ivnedar | yeah, fullscreen only |
| 03:34.21 | Ivnedar | I assume the zoning in process requires some acknowledgement from the client that it's good to go before completing |
| 03:34.28 | Ivnedar | and while it's alt-tabbed out, it doesn't respond |
| 03:34.44 | ZorbaTHut | yeah, it does, to prevent situations where you die by the time you've loaded |
| 03:34.53 | ZorbaTHut | I suspect the loading system just doesn't complete while alt-tabbed out |
| 03:35.22 | ZorbaTHut | actually, if I had to guess - directx probably loses the device when alt-tabbed out, and since part of the loading process involves loading textures into dx, it has to wait for you to alt-tab back in for that to complete |
| 03:35.31 | ZorbaTHut | which is also a part of why alt-tabbing back in can take a bit |
| 03:35.51 | ZorbaTHut | anyway afk a bit, food :) |
| 03:35.58 | Ivnedar | kinda amusing that you get rewards while in that state |
| 03:36.06 | Ivnedar | I guess it'd be erring on the side of the user in that case |
| 03:36.17 | Ivnedar | don't want them to alt-tab back in to find out they missed out on loot because they hit the wrong button |
| 03:48.02 | Imhothar1 | the DX device lost thing is a major pain in my book |
| 03:48.21 | Imhothar1 | loosing EGL context on some mobiles is quite terrible to work around too |
| 04:17.59 | *** join/#riftuidev Imhothar2 (~Adium@ppp-188-174-0-189.dynamic.mnet-online.de) |
| 04:18.20 | *** join/#riftuidev Imhothar_ (~Imhothar@ppp-188-174-0-189.dynamic.mnet-online.de) |
| 04:42.11 | ZorbaTHut | yeah context-losses are a colossal pain |
| 04:42.55 | Imhothar2 | that's something they did right on iOS, the only way to lose context is when the app terminates |
| 04:43.11 | *** join/#riftuidev Noshei (~quassel@c-24-9-171-99.hsd1.co.comcast.net) |
| 04:43.36 | Imhothar2 | and you don't need a surface to create a context, wich for some reason is still required on EGL |
| 04:44.25 | ZorbaTHut | it's been more of a performance hack up until now - early 3d accelerators didn't want to spend the RAM to keep the textures backed in main memory |
| 04:44.38 | ZorbaTHut | I seem to recall DX10 and DX11 finally did away with context losses |
| 04:44.56 | Imhothar2 | afaik they still happen on windows phone |
| 04:45.34 | Imhothar2 | but I may be wrong, it's been a very long time since I did DX |
| 04:45.51 | ZorbaTHut | I honestly don't know offhand if windows-phone is considered vanilla DX(something) or if they have their own custom variant |
| 04:46.04 | ZorbaTHut | I know the DX on the original XBox was a close relative of DX9 but not actually DX9 |
| 04:46.35 | Imhothar2 | I was quite disappointed when they kept context loss in EGL |
| 04:46.44 | Imhothar2 | it make your code so much more terrible |
| 04:47.15 | ZorbaTHut | yes :( |
| 04:48.21 | Imhothar2 | the way Android handles OpenGL is quite weird |
| 04:49.00 | Imhothar2 | whenever you rotate the device the current Activity is destroyed and recreated, so if you tie your OpenGL context to the view you happily reload all your assets on every device rotation |
| 04:49.52 | Imhothar2 | so you end up with some kind of solution that bypasses activity/view lifetime |
| 04:51.13 | Imhothar2 | and creating OpenGL contexts on Windows is still a pain |
| 04:51.28 | Imhothar2 | wonder if there is an EGL port |
| 04:59.47 | Imhothar2 | wonder if MS ever opens up OpenGL to Windows Phone |
| 05:00.16 | Imhothar2 | it's the only serious non-console platform that lacks OpenGL |
| 05:05.57 | Noshei | it is so strange moving around without moving your head or eyes very much |
| 05:06.15 | ZorbaTHut | noshei, vertigo still being annoying? |
| 05:06.21 | Noshei | yeah |
| 05:07.28 | Noshei | I learned a long time ago that if I have to move around that I have to move very deliberately with as little movement of my head and eyes as possible. It really makes you appreciate how much you move your head and eyes usually. |
| 07:39.34 | *** join/#riftuidev Imhothar (~Adium@p4FFB9657.dip0.t-ipconnect.de) |
| 10:06.31 | Ivnedar | hee hee, it's reminisce night in rift for our guild apparently |
| 10:06.39 | Ivnedar | people airing their bank contents |
| 11:10.56 | *** join/#riftuidev NuSuey (uid3556@gateway/web/irccloud.com/x-plaloeoketagzsmn) |
| 14:07.01 | *** join/#riftuidev Imhothar1 (~Adium@p4FFB9657.dip0.t-ipconnect.de) |
| 15:23.02 | Cairenn | Morning |
| 15:44.31 | *** join/#riftuidev Repo (~repo@76.164.170.2) |
| 16:05.14 | *** join/#riftuidev seebs (~seebs@home.seebs.net) |
| 16:05.14 | *** mode/#riftuidev [+o seebs] by ChanServ |
| 17:55.24 | *** join/#riftuidev Imhothar (~Imhothar@ppp-188-174-0-189.dynamic.mnet-online.de) |
| 18:03.19 | *** join/#riftuidev Imhothar1 (~Adium@ppp-188-174-0-189.dynamic.mnet-online.de) |
| 21:46.08 | *** join/#riftuidev Noshei (~quassel@c-24-9-171-99.hsd1.co.comcast.net) |
| 22:35.21 | *** join/#riftuidev seebs (~seebs@home.seebs.net) |
| 22:35.21 | *** mode/#riftuidev [+o seebs] by ChanServ |