You may want to look at existing base64 and base85 libraries, I once made a base93 library. which was the highest ascii code one I coudl get that worked across all languages and such I needed at the time.... a base255 makes no sense, though would just be bytes.
This is not compression by the way, this is encoding, it is used to encode a binary file (that can and usually then would be compressed) into a data stream that does not support an clean (usually meaning a full octec) channel for all bit patterns.
- Curse Premium
Member for 10 years, 8 months, and 16 days
Last active Wed, Dec, 6 2017 16:33:59
- 0 Followers
- 96 Total Posts
- 0 Thanks
Nov 11, 2008Posted in: UpdatersQuote from ciscohwell said.
It was my impression that WoWAce is a developers community, not a users community.
I will say, the moment Alphas become accessible via the client, i will move my repository to somewhere that lets me develop my way.
lol, actually I have started to set up my own repository as I am find that easier to do then figure out how to work with the curseforge one, it rejects all my attempts to put source code in saying I need to set some eol attribute, but I can find no way to do so till after it is checked in, maybe I should make it available to others also when I am done.
Nov 11, 2008Posted in: Updaters
You would literally be wasting my time if you reported bugs on some random commit I made. When I'm satisfied that the code is good enough to be tested, I'll tag it. This isn't curmudgeonly at all. It's the way software development works.
Dont know enough about svn yet, but maybe devl should be done on a branch then merged back to get this same effect?
Nov 11, 2008Anyway to label the commits as 'devel' then have the abilty to build alpha packages that are visiable to people who are logged in , and then have beta and release as they are now but release be what end users at curse see?Posted in: Updaters
Nov 11, 2008A large part of the problem is google seems to have started a trend where it is ok to keep calling something beta forever... alpha should be for a small private test group, and not used by many, beta should be packaged up with a wider test group, but not the default for all users, and things should be released for the version that is best tested and ready to run... but you can see some projects that never make a release version, hence beta is now release to a lot of people and alpha is what should be beta etc... and now we need a prealpha cat.Posted in: Updaters
Nov 11, 2008Posted in: LibrariesQuote from Squeeg
Unlike old cars, you don't take an old addon, rip out the insides, replace the entire thing and keep the exact same name.... typically.
Bah, getting too off topic I guess... but ...
I would, especially in the case of a library like routine in an enviorment with a global namespace. Does not seem to me the guts are what should be named, so much as the functionality.
Nov 10, 2008Posted in: Lua Code Discussion
I think Blizzard has proven to be more paranoid, and they drew the line at certain things. This is one of them.
Not really sure they did not already draw the line exactly here though, since you can turn on combat logging to disk....
Nov 10, 2008Posted in: Lua Code DiscussionQuote from egingellA split hair is still a hair. My point was that the author does not have real-time access to files.
Ah good, cause that point was not made in what you said, so I rephrased it to show it was not really saying anything by itself.
And, a logger still would not need to give them this is my point.
Nov 10, 2008Yeah, a log file should even be append only not just write only.Posted in: Lua Code Discussion
And yeah, a bot would have an add on pump out info to a file, and in effect 'tail -f' it... of course not doing this does not stop botting, just takes away an easy route to sync it with the game, so a delayed write should take care of that concern. Next of course you can write something to sniff the ram/cache, but then you can also just sniff the game if you are going that far.
Nov 10, 2008Posted in: Lua Code Discussion
same solution as they use for the existing log writing, a buffer and delay
Nov 10, 2008Posted in: Lua Code DiscussionQuote from FarmbuyerThe worst thing that a malicious addon author can do today is to keep adding huge strings of gibberish to a table, and then wait for the WoW client to write that table to disk as part of SavedVariables. No matter how big the table gets, it's tiny compared to the available disk space. At most, the table will use up the available memory and the player will have to restart the game.
If a malicious addon author can write directly to the drive, then they can just keep on appending data until the drive is filled, or until the file is large enough that the OS has problems with it. How many players would know what to look for to solve that problem, or even just to recover from it? We're not talking developers here, we're talking Grandpa and Grandson who enjoy questing together on the weekend being asked to find unusually large files in a subfolder that they didn't even know existed.
Even if it's sandboxed, you would have to have previously taken steps like isolating WoW to its own partition or other -- let's be honest -- unreasonable steps in order to safeguard against that. There are any number of ways to sort of prevent that, like size limitations monitored by the client, but (1) they probably would work most of the time but probably wouldn't be foolproof, and (2) they would likely eventually interefere with legitimate addons, because arbitrary restrictions eventually always do.
"Probably" does not make me feel warm and fuzzy about the security and stability of my computer. I think I'm just as happy knowing that addons can't see the drives. But that's just my opinion.
What about already being able to turn on the combat log? Solution here is to have a log rotation system built in the limits the length a file can be....
Nov 10, 2008Posted in: Lua Code DiscussionQuote from egingellSee, the thing is, the WoW client does that, not the addon author. The saved variables file is read into RAM, the addon(s) modify those variables while in RAM, and WoW dumps the data back to the file when the player logs out.
See the thing is , the OS does that, not the WoW client. The WoW client asked the OS to read the file into ram and the the WoW client asks the OS to dump the file to disk....
so.. umm. not really a logical difference we already have abstractiion layers.... and this point is not for any file writing anywhere on the system, it can be sandboxed .
- To post a comment, please login or register a new account.